Thursday, June 21st 2018

OpenBSD Turns Off Hyper-Threading to Combat Intel CPU Security Issues

Lead developer for OpenBSD Mark Kettenis has announced that OpenBSD will no longer enable Hyper-Threading on Intel processors by default. This move is intended to mitigate security exploits from the Spectre ecosystem as well as TLB and cache timing attacks, because important processor resources are no longer shared between threads. Their suspicion is that some of the unreleased (or yet unknown) attacks can be stopped using this approach.

This move is supported by the fact that most newer motherboards no longer provide an option to disable Hyper-Threading via BIOS. OpenBSD users who still want to use Hyper-Threading can manually enable support for it using the sysctl hw.smt. The developers are also looking into expanding this feature to other CPUs from other vendors, should they be affected, too.
The performance penalty from disabling Hyper-Threading is dependent on the software used. Highly optimized HPC software might even run faster without HT, other, more generic applications will see a performance hit. For example CineBench gains 30% with Hyper-Threading enabled.

Part of the reason why this change is happening now is due to criticism towards Intel, who keep failing at proper coordinated releases of exploits. Also Intel seems completely unresponsive to inquiries from the open source community. Only their buddies at big corporations like Apple, Google, Microsoft and Amazon get informed with enough lead time to prepare patches. That's why OpenBSD is taking the approach to immediately release a rough solution, while then waiting for Intel to come up with a fix that has a smaller performance impact. Source: OpenBSD Changelog Entry
Add your own comment

22 Comments on OpenBSD Turns Off Hyper-Threading to Combat Intel CPU Security Issues

#1
qubit
Overclocked quantum bit
I can't believe newer mobos don't allow HT to be turned off. :rolleyes: It's a basic configuration option. How dumb.
Posted on Reply
#3
trog100
does this effectively turn an I7 into an I5.. :)

trog
Posted on Reply
#4
R0H1T
"trog100 said:
does this effectively turn an I7 into an I5.. :)

trog
Spare a thought for the regular i3 buyer, they're getting locked Pentiums with extra l2/l3 cache :shadedshu:
Posted on Reply
#5
dj-electric
"TheGuruStud said:
This is when you love LOLtel.
LoLtel and NOvideo such shitty companies lolololololllll.
Posted on Reply
#6
Vya Domus
Weren't some developers behind OpenBSD allegedly paid to leave backdoors in their OS ? Funny they are being so considerate.
Posted on Reply
#7
RejZoR
So, Intel literally lost all the benefits because of security issues. First predictive cache and now HyperThreading. HT is huge deal. Is AMD's implementation of HT so different that they aren't affected?
Posted on Reply
#8
qubit
Overclocked quantum bit
"RejZoR said:
So, Intel literally lost all the benefits because of security issues. First predictive cache and now HyperThreading. HT is huge deal. Is AMD's implementation of HT so different that they aren't affected?
They are affected, but not to the same degree, apparently. There were various news reports about this if you want to know more details.
Posted on Reply
#9
R-T-B
"Vya Domus said:
Weren't some developers behind OpenBSD allegedly paid to leave backdoors in their OS ? Funny they are being so considerate.
More like they failed to vet government contractor provided code.

OpenBSD wasn't paid to insert them, they just failed to notice that paid "helpers" were slipping them in aparently useful commits.

Have a read:

https://www.theregister.co.uk/2010/12/15/openbsd_backdoor_claim/
Posted on Reply
#10
qubit
Overclocked quantum bit
"R-T-B said:
More like they failed to vet government contractor provided code.

OpenBSD wasn't paid to insert them, they just failed to notice that paid "helpers" were slipping them in aparently useful commits.

Have a read:

https://www.theregister.co.uk/2010/12/15/openbsd_backdoor_claim/
So the government might have been sliding backdoors into Linux on the sly? I find this very, very hard to believe. I'm sorry, but it's simply not possible.

/s
Posted on Reply
#11
Frick
Fishfaced Nincompoop
"qubit said:
So the government might have been sliding backdoors into Linux on the sly? I find this very, very hard to believe. I'm sorry, but it's simply not possible.

/s
nitpicking, but bsd =! Linux. ;)

Anyway, why is it not applied to amd?
Posted on Reply
#12
R0H1T
"Frick said:
nitpicking, but bsd =! Linux. ;)

Anyway, why is it not applied to amd?
AMD's smt implementation is different than Intel & more secure, for now.
Posted on Reply
#13
ShockG
This move is supported by the fact that most newer motherboards no longer provide an option to disable Hyper-Threading via BIOS
Pretty much have access to all the latest or at least high end boards starting at B360, H370, B350, X470, Z370 and X299 from at least 3 different board vendors.
I'd be interested to know which boards are these that don't allow disabling HT, which is actually in spec from INTEL.

On a sidenote, INTEL needs to get its act together, falling over themselves at every turn, with unforced errors. They are just fortunate their chief competitor is profoundly incompetent to some degree and unable to capitalize on these numerous short comings and failures from those in charge at INTEL (ThreadRipper sales are abysmal, when they should be killing INTEL's HEDT at every turn)
Posted on Reply
#14
Frick
Fishfaced Nincompoop
"R0H1T said:
AMD's smt implementation is different than Intel & more secure, for now.
yes, but i was after a more technical explanation.

"ShockG said:
Pretty much have access to all the latest or at least high end boards starting at B360, H370, B350, X470, Z370 and X299 from at least 3 different board vendors.
I'd be interested to know which boards are these that don't allow disabling HT, which is actually in spec from INTEL.

On a sidenote, INTEL needs to get its act together, falling over themselves at every turn, with unforced errors. They are just fortunate their chief competitor is profoundly incompetent to some degree and unable to capitalize on these numerous short comings and failures from those in charge at INTEL (ThreadRipper sales are abysmal, when they should be killing INTEL's HEDT at every turn)
Are they abysmal though? I haven't seen any numbers, but for what it's worth tr ranks higher than intel hedt on a popular price comparision site where i live. Would be nice to see concrete numbers though.
Posted on Reply
#15
TheinsanegamerN
"Frick said:

Are they abysmal though? I haven't seen any numbers, but for what it's worth tr ranks higher than intel hedt on a popular price comparision site where i live. Would be nice to see concrete numbers though.
AMD hasnt released hard numbers. Their quarterly financial statements show that, while sales and revenue are up, they haven't exploded onto the market like some predicted. The HDET market is quite small compared to the server market, where EPYC is still in the process of rolling out.
Posted on Reply
#16
efikkan
This action by the OpenBSD team seems hardly justified, the known security implications of SMT are maintainable when implemented properly.

The bigger discussion we should have is rather if SMT still makes sense for future CPUs. The purpose of SMT is to utilize the idle resources in the CPU to other threads while the execution is stalled due to branch mispreditions, data dependencies or cache misses. SMT may gain total throughput across multiple threads at the price of decreased throughput for a single thread, and "marginal" cost of implementation compared to a whole new CPU core.

Intel implemented HT at a time their Pentium 4 ("Netburst") architecture was struggling due to an inefficient design. At this time CPUs were single core, but multi-CPU setups existed for the enterprise market. The cost of implementation was relatively marginal, both for the front-end/prefetcher and the execution units. Making a single core have some powers of a "dual core" made sense at the time, and not only for marketing purposes, at the time it made scheduling easier and systems potentially less "hanging". It's worth mentioning that IBM's Power CPUs support 4-/8-way SMT, mainly used for executing massive amounts of threads of enterprise Java code, which normally have huge amounts of stalls due to cache misses.

But does SMT still make sense today, at least if we narrow our scope to desktops and laptops?
Performance:
The average gains is in the range of ~5%. The cases where we see 30% gains are edge-cases, there are also many cases where we see performance loss of >10%. Any synchronized workload risk losing performance with SMT, including gaming, audio processing, etc. SMT also introduces performance variability and higher latency.
Die cost:
While the cost of implementation of SMT in Pentium 4 was relatively low, modern CPU architectures relies more and more on their front-end; the prefetcher. This doesn't only add security implications, but also a strain on the prefetcher's resources, and of course the cache. Intel usually adds more L3 cache, but it's not enough to compensate for the performance loss. We are already at a point where the design cost of SMT is much greater than when it was introduced, and since we can easily add more cores to a design today, it makes more sense to prioritize more faster cores rather than cores with SMT. As we go forward, future CPU architectures is only going to be more advanced, and SMT adds more and more restrictions on the design choices.
Software - OS:
The kernel obviously have to be aware of SMT, and treats the CPU as x "strong" cores and x "weak" cores. This might have been simple when most computers had 1 core, but today with even HEDT soon getting >20 cores, this complexity becomes completely unnecessary.
Software - programs:
It's harder for a single program with many threads to scale well if SMT than for multiple programs. E.g. on an 8-core, some workloads will scale better with 8 threads, while others scale better with 16 threads. This comes down to how efficient the code is, and more efficient code will cause fewer stalls in the CPU, so there are fewer idle cycles to use for other threads. If the program assumes all threads are equal, splitting a workload into 16 threads vs. 8 threads may reduce performance (on the same 8-core CPU). SMT only really works well when you have a mix of "heavy" threads and "light" threads, and no need to synchronize them.

My assessment is that the costs of SMT are increasing while the gains are decreasing, and we're approaching a point where it will soon be "pointless". I would much rather trade an 8-core/16-thread CPU design for one that's either a faster 8-core or a 10-core instead.
Posted on Reply
#17
Rockarola
Thank you! This is why I still come to the forums...great info, short and to the point.
Posted on Reply
#18
Hood
"trog100 said:
does this effectively turn an I7 into an I5.. :)

trog
No, this makes you go out and buy the new 8-core Intel, so you can still have 8 threads with HT turned off. At least it will overclock a little higher without HT enabled.
Posted on Reply
#19
lexluthermiester
"TheGuruStud said:
This is when you love LOLtel.
That firmware option is not Intel's purview. It is up to system/mobo builder to enable it in their product. Blame the manufacturers for this one, not AMD/Intel.

"Vya Domus said:
Weren't some developers behind OpenBSD allegedly paid to leave backdoors in their OS ? Funny they are being so considerate.
Citation please?

"qubit said:
I'm sorry, but it's simply not possible.
Well, let's be fair, it is possible, but very unlikely and if did happen it'd be found swiftly, so..

"R0H1T said:
AMD's smt implementation is different than Intel & more secure, for now.
Key point.
Posted on Reply
#20
qubit
Overclocked quantum bit
"Frick said:
nitpicking, but bsd =! Linux. ;)

Anyway, why is it not applied to amd?
Ya, I was thinking open source and then wrote Linux. Brain fart, lol.

"lexluthermiester said:
Well, let's be fair, it is possible, but very unlikely and if did happen it'd be found swiftly, so..
I was being sarcastic. :) Note the /s underneath my post. Of course they'd be only too willing to stick in backdoors. Remember the mini scandal with that dead terrorist's iPhone that they couldn't crack? They were trying to force Apple into putting backdoors into iOS.
Posted on Reply
#21
lexluthermiester
"qubit said:
I was being sarcastic. :) Note the /s underneath my post. Of course they'd be only too willing to stick in backdoors. Remember the mini scandal with that dead terrorist's iPhone that they couldn't crack? They were trying to force Apple into putting backdoors into iOS.
I understood you. No worries.
Posted on Reply
#22
newtekie1
Semi-Retired Folder
"R0H1T said:
Spare a thought for the regular i3 buyer, they're getting locked Pentiums with extra l2/l3 cache :shadedshu:
Unless they have the latest gen i3, in which case they aren't losing anything.

Plus, its not like people can't just re-enable it. It is just an option that is now off by default instead of on by default.
Posted on Reply
Add your own comment