Slashdot Mirror
OpenBSD Disables Intel CPU Hyper-Threading Due To Security Concerns (bleepingcomputer.com)
The OpenBSD project announced today plans to disable support for Intel CPU hyper-threading due to security concerns regarding the theoretical threat of more "Spectre-class bugs." Bleeping Computer reports: Hyper-threading (HT) is Intel's proprietary implementation of Simultaneous Multithreading (SMT), a technology that allows processors to run parallel operations on different cores of the same multi-core CPU. The feature has been added to all Intel CPUs released since 2002 and has come enabled by default, with Intel citing its performance boost as the main reason for its inclusion.
But today, Mark Kettenis of the OpenBSD project, said the OpenBSD team was removing support for Intel HT because, by design, this technology just opens the door for more timing attacks. Timing attacks are a class of cryptographic attacks through which a third-party observer can deduce the content of encrypted data by recording and analyzing the time taken to execute cryptographic algorithms. The OpenBSD team is now stepping in to provide a new setting to disable HT support because "many modern machines no longer provide the ability to disable hyper-threading in the BIOS setup."
But today, Mark Kettenis of the OpenBSD project, said the OpenBSD team was removing support for Intel HT because, by design, this technology just opens the door for more timing attacks. Timing attacks are a class of cryptographic attacks through which a third-party observer can deduce the content of encrypted data by recording and analyzing the time taken to execute cryptographic algorithms. The OpenBSD team is now stepping in to provide a new setting to disable HT support because "many modern machines no longer provide the ability to disable hyper-threading in the BIOS setup."
In an interview, Theo de Raadt stated that other measures were considered by OpenBSD to fight the threats posed by Spectre, Meltdown and the new line of harmful code. "There will for sure be a trade-off between cutting edge performance and real security", de Raadt said.
One of the poweful options considered - that would permanently repel all current threats but didn't make it into final release, was making the power supply option off by default.
No, it shouldn't because security should have higher priority over speed. If people want to run their computer in a less secure mode they can do so themselves after making an informed decision and accepting the risks it includes. The default state should be the more secure mode so that it covers everyone.
+1 to the OpenBSD project for putting security above speed.
-1 to intel for putting speed above security.
When you turn off hyperthreading Intel and AMD are much more closer to each other. This is why my next major computer build will be AMD. I will have speed and security.
Given the class of Spectre and Meltdown attacks rely on someone else having the freedom to execute code on your hardware, shouldn't something like this be opt-in? There's a whole world of servers out that where Spectre is ultimately completely irrelevant in terms of a security threat, but hyperthreading is definitely not irrelevant in terms of performance.
I can't do any better than quote OpenBSD on this:
OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there). Our open software development model permits us to take a more uncompromising view towards increased security than most vendors are able to. We can make changes the vendors would not make.
https://www.openbsd.org/security.html
As you can read in their statement, they want to be secure. Being usable is not one of their priorities.
This is your sig. There are thousands more, but this one is yours.
"a technology that allows processors to run parallel operations on different cores of the same multi-core CPU"
Not it's not. It's a technology that allows processors to present a single physical core as two logical cores. Two threads of software can run simultaneously on a single physical core.
It's mostly an optimization of the execution pipeline. When execution in one thread stalls, it can pick up processing in the other thread. It typically boosts performance by about 10-20%. And yes, I can see this could cause problems regarding timing if you can cause a pipeline stall based on a condition you want to test in the other thread on the same core. It'll be hard though. Maybe too hard to justify disabling HT altogether. Providing a switch to turn it off in case an exploit is discovered would be more wise I think.
This is your sig. There are thousands more, but this one is yours.
For AMD's SMT implementation, it's around 30% in heavy workloads. Hell, a Cinebench test by a Czech web site reported a 40% speed boost in Cinebench R15 for an 1800X. On Reddit, a 45% difference was reported for a 1600X.
Ezekiel 23:20
It's an option, you can change the setting with a syscall. That's not clear from the summary, you have to click through to the actual announcement.
"First they came for the slanderers and i said nothing."
However, I forgot to add, for OpenBSD, it may not make that much of a difference - they've never been particularly fast, especially on SMP machines, so perhaps the impact on OpenBSD is disproportionately lower and therefore acceptable? Someone should measure this.
Measure? Measure?!!?! MEASURE???!?! Are you fucking nuts? Why would anyone want to actually measure this when we can have a 2,752-message thread based purely on random anecdotes and opinions arguing over whether there's a difference or not.
(Wanders off muttering "Measure. He wants to measure").
My mode points expired yesterday, so you'll have a comment instead.
Why the fuck would you need an opt-in for a security feature?
"Your data are set to be stolen by default. To change the settings please refer to the respective manual"
Why the fuck isn't data mining, spying, advertising(in windows and ubuntu) opt-in, instead everything bad is opt-out
and now we see people asking for security features to be opt-in.
If you are concerned about that administrator that has to flip a value to enable the security holes in his system, it's his job, you don't have to think about him.
You'll have to think about your average joe, who wants to use *BSD or Linux and isn't specializing in infosec or isn't yet familiar with those terms and practices.
(yes, there are people who aren't programmers, who know how to use bsd and linux)
First of all, it surely looks like OpenBSD developers don't even have a working spellchecker and perhaps they are correct, saying that it doesn't necessarily have a "posive" effect.
However, in all seriousness, I've seen at least two dozens tests of HT and in the worst case scenario it slows down your performance by less than a few percents, however, when we're talking servers, which nowadays run highly parallelized workloads where a single process may span several cores (nginx, mariadb, redis, mongodb, etc. etc. etc.) the performance gain from using HT may reach up to 30%, i.e. you're getting a third of your cores for free, which allows you to greatly cut expenditures and save on cooling.
Yes, HT poses security challenges in a multiuser environment (say, for a hosting provider) where people might run any code they want, however a typical application server almost always runs a tightly controlled software stack, which means your server processes cannot run any foreign code, which means Meltdown/Spectre class attacks might be safely disregarded.
It's true. OpenBSD does not benefit from hyper-threading, at least on all Intel platforms I have tried. Having it off happens to be a small net-win for performance as well (a few percent on compile tests). This isn't just true for OpenBSD or for every workload either. Your mileage obviously may vary and should be tested.
iPhone users:
Settings > General > Keyboard ... set "Smart Punctuation" to Off.
You're killing us with this shit, it's unreadable.
OpenBSD is adding a control to turn off hyper-threading (because some BIOSes these days don't have such a control), and is turning it off by default on Intel CPUs. But it can be turned on again. So OpenBSD is providing control, not taking it away. Read for yourself. https://undeadly.org/cgi?actio...
The current release of OpenBSD, version 6.3, has issued a total of 10 patches against base since release on April 15th. Four of these are security-related, and six are reliability bug fixes.
Oracle / Red Hat Linux in that time has issued 50 security-related patches, and hundreds more that are classed as bug fixes or enhancements.
Linux is strong because it scales up and down very well, it exploits CPU features for speed to make applications run very fast, it is friendly to new features, and it has the most market share in the POSIX realm. Linux is weak because it has sacrificed security for speed in many cases, and we have Dirty Cow, Towelroot, and many similar problems in userspace - this makes Linux a bad choice for systems that will not receive patches (i.e. phones, IoT devices, embedded systems, etc.).
OpenBSD prioritizes security over speed and flexibility. It does not implement fine-grained SMP due to security concerns, and has a "big kernel lock" that Linux left behind in 2.2. It ignores many well-known standards (i.e. NFSv4). There are many things that you cannot do on OpenBSD, but what you can do is magnitudes safer than Linux.
Android politely stole OpenBSD's entire libc implementation (and then ignored it for several years), and IIRC the OpenBSD code is the largest contribution outside of the kernel itself.
OpenBSD is also the home of OpenSSH, which itself is quite secure.
I trust the opinions of the OpenBSD kernel architects, and I will look forward to their patch.