OpenBSD disables Intel’s hyper-threading over CPU data leak fears

June 23, 2018 TH Author

OpenBSD has disabled Intel’s hyper-threading technology, citing security concerns – seemingly, Spectre-style concerns.

As detailed in this mailing list post, OpenBSD maintainer Mark Kettenis wrote that “SMT (Simultaneous Multi Threading) implementations typically share TLBs and L1 caches between threads.

“This can make cache timing attacks a lot easier and we strongly suspect that this will make several Spectre-class bugs exploitable.”

So OpenBSD has decided to disable Intel CPU hyper-threading, with “a new hw.smt sysctl,” in order to avoid data potentially leaking from applications to other software via Spectre-like processor flaws.

“For now this only works on Intel CPUs when running OpenBSD/amd64,” Kettenis wrote. “But we’re planning to extend this feature to CPUs from other vendors and other hardware architectures.”

Insane in the domain

There’s not much more by way of explanation for the decision in Kettenis’ post, other than the observation that: “We really should not run different security domains on different processor threads of the same core.”

There is, however, a further hint about the reason in this post from OpenBSD chap Philip Guenther, who committed a change to “clear the GPRs when entering the kernel from userspace so that user-controlled values can’t take part in speculative execution in the kernel down paths that end up ‘not taken’ but that may cause user-visible effects (cache, etc).”

That commit was accompanied by a request to disable Intel hyper-threading.

We’ve also spotted this Seclists message mentioning OpenBSD’s decision, and hinting a related disclosure coming on June 27. And this talk at Black Hat in August that promises to reveal how miscreants can extract encryption keys from application memory via hyper-threading and TLB data leaks.

Specifically, that presentation, by Ben Gras, will cover a technique dubbed TLBleed that exploits hyper-threading to swipe sensitive data:

We’ve asked Kettenis to offer more information, and Intel to comment, but neither had been in touch at the time of writing.

Performance

Kettenis’ post suggest disabling hyper-threading won’t be a big deal because “SMT doesn’t necessarily have a positive effect on performance; it highly depends on the workload. In all likelihood it will actually slow down most workloads if you have a CPU with more than two cores.”

He’s not wrong: unless code is written with hyper-threading in mind, the performance benefit isn’t enormous, and not a lot of code specifically takes advantage of the feature. Hyper-treading works by allowing one CPU core to run multiple threads at once, as opposed to one thread per core.

Intel, however, markets hyper-threading as a distinct virtue: its CPU spec sheets always mention core and thread count.

Hints of further Spectre-like security worries will therefore be most unwelcome to Chipzilla. The OpenBSD community was miffed by the steps taken to disclose Meltdown and Spectre design flaws – effectively freezing out a chunk of the BSD world from private collaborations on mitigations – and called for such revelations to be handled differently in future. ®

Sponsored: Minds Mastering Machines – Call for papers now open