
Kernel Side-Channel Attacks - jjuhl
https://access.redhat.com/security/vulnerabilities/speculativeexecution
======
wyldfire
It strikes me as odd that Project Zero is listed as having discovered this in
mid-2017. It seems like this vulnerability and the browser mitigations being
considered only just now were discussed quite some time ago:

This comment was on April 7, 2017:
[https://news.ycombinator.com/item?id=14057091](https://news.ycombinator.com/item?id=14057091)

And this one from 2015?
[https://github.com/tc39/ecmascript_sharedmem/issues/1](https://github.com/tc39/ecmascript_sharedmem/issues/1)

~~~
sethev
The new discovery was that there's a speculative execution side channel. Those
links are discussing the potential of a cache side channel which is very
different thing. It's the difference between "i might be able to infer some
things that are in the cache that something else put there" and "please give
me the contents of this address".

------
usernam
Can somebody shed some light in what exactly the released Intel Microcode
update does aside from exposing some chicken bits? This is only marginally
addressed in the "Controlling the Performance Impact" page linked above.

For example, does the update fix Meltdown in any meaningful way? If so, does
it mean that "pti" should be manually disabled on a patched intel cpu to avoid
_additional_ overhead?

It seems that the kernel changes being pushed do not account for the current
published microcode updates.

~~~
cesarb
According to
[https://access.redhat.com/articles/3311301](https://access.redhat.com/articles/3311301)
PTI should be enabled on Intel even with the new microcode, so the microcode
update probably doesn't fix variant 3 (Meltdown).

Also, I don't think the microcode updates just expose some chicken bits. IBRS
seems to be exposing one or more chicken bits as a single bit, but IBPB seems
to be a command to run a routine in the microcode to immediately clear part of
the branch predictor state, not a chicken bit.

Yes, the kernel changes in the Linus tree only fix variant 3, there are
several partial and/or mutually incompatible patch sets being posted on the
linux kernel mailing list to fix the other variants; the Red Hat kernel seems
to have an early version of some of these. See also the just posted
[http://kroah.com/log/blog/2018/01/06/meltdown-
status/](http://kroah.com/log/blog/2018/01/06/meltdown-status/) for more
detail.

~~~
usernam
I read both, and I can confirm that meltdown is not fixed by the microcode
update alone. But I'm confused by intel claiming a fix for all three variants
of exploits: I would have realistically expected a proper fix for meltdown,
but it seems that intel can't really fix it in microcode.

------
rpns
The two knowledge base articles linked are also interesting:

Speculative Execution Exploit Performance Impacts - Describing the performance
impacts to security patches for CVE-2017-5754 CVE-2017-5753 and CVE-2017-5715

[https://access.redhat.com/articles/3307751](https://access.redhat.com/articles/3307751)

Controlling the Performance Impact of Microcode and Security Patches for
CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753 using Red Hat Enterprise Linux
Tunables

[https://access.redhat.com/articles/3311301](https://access.redhat.com/articles/3311301)

------
hvindin
Is someone more informed on the workings of the Linux kernel (specifically
redhats flavour) able to point me in the direction of some more detail about
this:

 __Due to the nature of changes required, a kpatch for customers running Red
Hat Enterprise Linux 7.2 or greater will NOT be available __

Just wondering what changed between 7.1 - > 7.2 that made this something that
couldn't be updated live and there doesn't seem to be a ton of obvious extra
information about the nuances of this change around.

~~~
gtirloni
kpatch was a Technology Preview in 7.1 and only became officially supported in
7.2

[https://access.redhat.com/documentation/en-
us/red_hat_enterp...](https://access.redhat.com/documentation/en-
us/red_hat_enterprise_linux/7/html/7.2_release_notes/kernel)

~~~
hvindin
> kpatch was a Technology Preview in 7.1 and only became officially supported
> in 7.2

> [https://access.redhat.com/documentation/en-
> us/red_hat_enterp...](https://access.redhat.com/documentation/en-
> us/red_hat_enterp..).

Ah, I completely missed that it was a technology preview in 7.1

Presumably what that snippet is actually saying is "there will be no way to
avoid a reboot due to the nature of this change" rather than "rhel 7.2+ will
require a reboot but 7.0 and 7.1 won't"

Thanks for the clarification.

