OpenBSD disables Intel's hyperthreading due to security concerns

&gt; 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.<p>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&#x27;t. Given that hyperthreads share L1 cache, this might also be better for performance.

So... they &quot;strongly suspect&quot; (but don&#x27;t know and haven&#x27;t shown) there may be a Spectre-class bug enabled by current HT implementations and improving their scheduler is hard, so they&#x27;ll pre-emptively disable HT outright on Intel CPUs now and others in the near future?<p>I&#x27;m not an OpenBSD user (and glad for it, if this is anything to go by), but I&#x27;m curious - is this really how they operate, or does this decision stand out?

I&#x27;ve never trusted hyperthreading for workloads I haven&#x27;t tested. Sometimes it&#x27;s faster, often it&#x27;s slower. Beyond that, I&#x27;ve been suspicious of its security implications from day one. My first trip through the BIOS on a personal machine always includes turning it off.

There are some Linux HT benchmarks here: <a href="https:&#x2F;&#x2F;www.phoronix.com&#x2F;scan.php?page=article&amp;item=intel-ht-2018&amp;num=1" rel="nofollow">https:&#x2F;&#x2F;www.phoronix.com&#x2F;scan.php?page=article&amp;item=intel-ht...</a>

Do you get the exact same performance characteristics by ignoring the extra virtual cores as you would have gotten if you could actually disable hyperthreading in the CPU via the firmware setup? Or does it result in some CPU resources becoming unusable that would otherwise be usable if HT were truly disabled?

Ouch. 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).<p>When you have four-six-eight or more cores, there&#x27;s less value in doubling that number. The gain is lower.

The implication seems to be that other architectures are also soon to have SMT disabled by default. That would definitely hurt POWER, for example.

I was going to submit this news from the source I learned it from, which has the novel peculiarity of coming from a site that&#x27;s name is similar to this one: <a href="https:&#x2F;&#x2F;thehackernews.com&#x2F;thn&#x2F;2018&#x2F;06&#x2F;openbsd-hyper-threading.html" rel="nofollow">https:&#x2F;&#x2F;thehackernews.com&#x2F;thn&#x2F;2018&#x2F;06&#x2F;openbsd-hyper-threadin...</a>

Does anyone know when they are going to patch this or is it a permanent fix?

i didnt see this posed in the comments, but it was certainly tops on my mind. is this the same issue for linux kernel?

They should make it easier to find the diff behind all openbsd emails. I can’t find this one.

Ouch. Huge hit for performance.

What scares me is that they do OS wide change based of wording &quot;This can make&quot;, &quot;And since we suspect&quot; and &quot;In all likelyhood&quot; instead of doing actual tests. I know that open systems doesn&#x27;t have required workforce, but doing changes based on subjective reasoning is slippery slope.

FFS: so far I&#x27;ve seen shit loads of &quot;oooo - stuff &lt;wave hands&gt;&quot; here from people who are clearly not experts or even understand the issues properly in this. Neither am I.<p>OP (and environs) has names on it that I have seen before and respect as knowing what the hell they are on about.