Re: Meltdown and spectre

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> 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>
> 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