RE: Meltdown and spectre

Would this help revive the fortunes of depleting RISC based processors? Only time will tell.

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Tim Hall Sent: Saturday, January 6, 2018 12:57 PM To: Franck Pachot <franck_at_pachot.net> Cc: Hans Forbrich <fuzzy.graybeard_at_gmail.com>; Oracle-L Freelists <oracle-l_at_freelists.org> 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_at_pachot.net<mailto:franck_at_pachot.net>> wrote: Hi Tim,

It seems there's only the Spectre patches, but not the Meltdown

[root_at_VM120 oracle]# rpm -q kernel-uek

kernel-uek-4.1.12-112.14.5.el7uek.x86_64

[root_at_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_at_oracle-base.com<mailto:tim_at_oracle-base.com>> 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_at_oracle-base.com<mailto:tim_at_oracle-base.com>> 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_at_gmail.com<mailto:fuzzy.graybeard_at_gmail.com>> 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

--
http://www.freelists.org/webpage/oracle-l