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