Hacker News Reader

Comment by zik | Hacker News Reader

No, as he points out in the article even a kernel call can change the virtual address space so even two threads of the same program may leak data. There's basically no known fix except to disable hyperthreading entirely.

View on HN

Yes I meant more generally - effectively: at what point do we trust that there are no side channels in a modern cpu?

It seems they are complex enough that the answer may be "never", at least for some high risk scenarios.

> There's basically no known fix except to disable hyperthreading entirely.

on kabylake & skylake this has been the recommendation anyway https://lists.debian.org/debian-devel/2017/06/msg00308.html

That was the recommendation before the microcode fixes for the issue became widely available.

For more on which, see the news from a few days ago:

* https://www.mail-archive.com/source-changes@openbsd.org/msg9... (https://news.ycombinator.com/item?id=17350278)

If you pin VMs to different cores, never sharing hyperthreads, then the risk is contained per VM (or per core).

Let's hope there's no inter-core side-channel lurking in the shadows :(

It is time to rethinking the engineering methodologies we use in the electronics/informatics field.

Breaking x86 backward compatibility? That would be fun.

So we are between a rock and a hard place.

If you give two threads on one core to one VM, the VM could attack the hypervisor. It could have one thread run the TLB probe loop while the other does something that's handled by the hypervisor.

Isn’t there typically a VMM per VM? So the risk is then lower?

http://3.bp.blogspot.com/-OyjQUpLowmg/Udz1_NxqNLI/AAAAAAAABV...

Reply on news.ycombinator.com