4 ms·

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 basic

by zik 8y ago

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.

alkonaut 8y ago
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.
DyslexicAtheist 8y ago
> 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 https://lists.debian.org/debian-devel/2017/06/msg00308.html
- tambre 8y ago
  That was the recommendation before the microcode fixes for the issue became widely available.
pas 8y ago
If you pin VMs to different cores, never sharing hyperthreads, then the risk is contained per VM (or per core).
- pabloski 8y ago
  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.
  - cm2187 8y ago
    Breaking x86 backward compatibility? That would be fun.
    - pabloski 8y ago
      So we are between a rock and a hard place.
- pocak 8y ago
  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.
  - AlphaSite 8y ago
    Isn’t there typically a VMM per VM? So the risk is then lower? http://3.bp.blogspot.com/-OyjQUpLowmg/Udz1_NxqNLI/AAAAAAAABV8/-kBslSjUXUg/s1600/VMM.jpg http://3.bp.blogspot.com/-OyjQUpLowmg/Udz1_NxqNLI/AAAAAAAABV...
JdeBP 8y ago
For more on which, see the news from a few days ago: * https://www.mail-archive.com/source-changes@openbsd.org/msg99141.html https://www.mail-archive.com/source-changes@openbsd.org/msg9... (https://news.ycombinator.com/item?id=17350278 https://news.ycombinator.com/item?id=17350278)

by zik 8y ago

alkonaut 8y ago

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.

DyslexicAtheist 8y ago

> 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 https://lists.debian.org/debian-devel/2017/06/msg00308.html

tambre 8y ago
That was the recommendation before the microcode fixes for the issue became widely available.

pas 8y ago

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

pabloski 8y ago
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.
- cm2187 8y ago
  Breaking x86 backward compatibility? That would be fun.
  - pabloski 8y ago
    So we are between a rock and a hard place.
pocak 8y ago
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.
- AlphaSite 8y ago
  Isn’t there typically a VMM per VM? So the risk is then lower? http://3.bp.blogspot.com/-OyjQUpLowmg/Udz1_NxqNLI/AAAAAAAABV8/-kBslSjUXUg/s1600/VMM.jpg http://3.bp.blogspot.com/-OyjQUpLowmg/Udz1_NxqNLI/AAAAAAAABV...

JdeBP 8y ago

For more on which, see the news from a few days ago: * https://www.mail-archive.com/source-changes@openbsd.org/msg99141.html https://www.mail-archive.com/source-changes@openbsd.org/msg9... (https://news.ycombinator.com/item?id=17350278 https://news.ycombinator.com/item?id=17350278)