Would this help revive the fortunes of depleting RISC based processors? Only
time will tell.
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Tim Hall
Sent: Saturday, January 6, 2018 12:57 PM
To: Franck Pachot <franck@xxxxxxxxxx>
Cc: Hans Forbrich <fuzzy.graybeard@xxxxxxxxx>; Oracle-L Freelists
<oracle-l@xxxxxxxxxxxxx>
Subject: Re: Meltdown and spectre
Interesting. I wonder if they were just getting those out of the door quickly,
or if there is some other reason for that. I'm sure there will be a blog
announcement at some point...
On Sat, Jan 6, 2018 at 5:43 PM, Franck Pachot
<franck@xxxxxxxxxx<mailto:franck@xxxxxxxxxx>> wrote:
Hi Tim,
It seems there's only the Spectre patches, but not the Meltdown
[root@VM120 oracle]# rpm -q kernel-uek
kernel-uek-4.1.12-112.14.5.el7uek.x86_64
[root@VM120 oracle]# rpm -q --changelog kernel-uek | awk
'/CVE-2017-5715|CVE-2017-5753|CVE-2017-5754/{print $NF}' | sort -u
{CVE-2017-5715}
{CVE-2017-5753}
Regards,
Franck.
On Sat, Jan 6, 2018 at 3:05 PM Tim Hall
<tim@xxxxxxxxxxxxxxx<mailto:tim@xxxxxxxxxxxxxxx>> wrote:
Forgot to include this...
Removed:
kernel-uek.x86_64 0:4.1.12-103.10.1.el7uek
kernel-uek-devel.x86_64 0:4.1.12-103.10.1.el7uek
kernel-uek-firmware.noarch 0:4.1.12-103.10.1.el7uek
Installed:
kernel-uek.x86_64 0:4.1.12-112.14.5.el7uek
kernel-uek-devel.x86_64 0:4.1.12-112.14.5.el7uek
kernel-uek-firmware.noarch 0:4.1.12-112.14.5.el7uek
Complete!
On Sat, Jan 6, 2018 at 2:03 PM, Tim Hall
<tim@xxxxxxxxxxxxxxx<mailto:tim@xxxxxxxxxxxxxxx>> wrote:
Some UEK4 patches have just appeared that weren't there yesterday. I've not
checked the contents, but it would be rather coincidental if they weren't
related to this. :)
On Fri, Jan 5, 2018 at 11:51 PM, Hans Forbrich
<fuzzy.graybeard@xxxxxxxxx<mailto:fuzzy.graybeard@xxxxxxxxx>> wrote:
On 2018-01-05 2:33 PM, Reen, Elizabeth (Redacted sender elizabeth.reen for
DMARC) wrote:
I have a background in system engineering. I don’t get how a chip can be
exploited. What code can be hacked there?
For speculative execution, a command is executed that MIGHT be required. That
command might ask to move stuff into some portion of memory, or need a specific
page moved in. If that command is then rolled back, what happens to the memory
that it just filled? (Hint: it's still filled in, perhaps with a password.)
Back in the day (early 90s) when this stuff was dreamt up, the idea of flushing
that memory on command rollback would not have been a concern - hacking was for
fun, not profit, in those days. It's not actually the code being hacked, as
much as a side effect that is not properly handled.
It wasn't just the hardware guys, either. We s/w devs were pretty sloppy about
things like end-of-arrays and random pointers in our code, and few people
worried about (or even understood) what happened at the chip level. (Remember
why Java came into being?)
/Hans
