OpenBSD disables Intel's hyperthreading due to security concerns
mail-archive.com
OpenBSD disables Intel's hyperthreading due to security concerns
1–10 of 158 posts
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#2Ouch. I will say though, Hyper-Threading is a lot less valuable these days than it was when it was first introduced (except for the few dual core CPUs still available).
When you have four-six-eight or more cores, there's less value in doubling that number. The gain is lower.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#3The implication seems to be that other architectures are also soon to have SMT disabled by default. That would definitely hurt POWER, for example.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#4> We really should not run different security domains on different processor threads of the same core. Unfortunately changing our scheduler to take this into account is far from trivial.
This suggests a long-term compromise solution where threads within a process can use hyperthreading to share a core, but threads in different processes can't. Given that hyperthreads share L1 cache, this might also be better for performance.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#5Ouch. I will say though, Hyper-Threading is a lot less valuable these days than it was when it was first introduced (except for the few dual core CPUs still available). When you have four-six-eight or more cores, there's less value in doubling that number. The gain is lower.
It's still important to hide latency and saturate the memory controllers for programs with irregular memory accesses (e.g. graph algorithms), although the difference is not 2x, but something more like 10-15% over running without hyper-threading.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#6> We really should not run different security domains on different processor threads of the same core. Unfortunately changing our scheduler to take this into account is far from trivial. This suggests a long-term compromise solution where threads within a process can use hyperthreading to share a core, but threads in different processes can't. Given that hyperthreads share L1 cache, this might also be better for perf…
I'm not sure that would necessarily fix the problem definitively. Say you had a browser running web-exposed JavaScript on a thread. You could still finagle a Spectre-type information leak that way by having the JavaScript thread snoop other browser threads, assuming no other mitigations.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#7> We really should not run different security domains on different processor threads of the same core. Unfortunately changing our scheduler to take this into account is far from trivial. This suggests a long-term compromise solution where threads within a process can use hyperthreading to share a core, but threads in different processes can't. Given that hyperthreads share L1 cache, this might also be better for perf…
I'm not sure that would necessarily fix the problem definitively. Say you had a browser running web-exposed JavaScript on a thread. You could still finagle a Spectre-type information leak that way by having the JavaScript thread snoop other browser threads, assuming no other mitigations.
Don't most browsers run one process per page/tab nowadays?
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#8Earlier quoted context omitted.
I'm not sure that would necessarily fix the problem definitively. Say you had a browser running web-exposed JavaScript on a thread. You could still finagle a Spectre-type information leak that way by having the JavaScript thread snoop other browser threads, assuming no other mitigations.
Don't most browsers run one process per page/tab nowadays?
Chrome does, Firefox does not (I've got 5 processes for a billion tabs.)
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#9Re: OpenBSD disables Intel's hyperthreading due to security concerns
#10Ouch. I will say though, Hyper-Threading is a lot less valuable these days than it was when it was first introduced (except for the few dual core CPUs still available). When you have four-six-eight or more cores, there's less value in doubling that number. The gain is lower.
On the other side, a hyperthreaded CPU used to be about 10 - 30% gain, but in tests I've ran on recent hardware (HP DL380 Gen 10) hyperthreading gives around 70% more performance (the test I used was running pigz [parallel gzip] on a large file).