Kernel Side-Channel Attacks | Hacker News Reader

Kernel Side-Channel Attacks

access.redhat.com

98 pointsjjuhl11 comments

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

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

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

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.

According to 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/ for more detail.

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.

There is a whole technical paper by Intel on this.

* https://news.ycombinator.com/item?id=16079910

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

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

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.

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

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

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.

I think this is related to kpatch only being available as of RHEL 7.2 [1] in general. In other words, this must not necessarily be caused by any specifics of the current kernel patches.

[1] https://access.redhat.com/articles/2475321#scope

Reply on news.ycombinator.com