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."
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 wonder if there is another Spectre-variant, that the OpenBSD developers know about, but we don't yet, where Hyperthreading really matters. WE know there are a few more SpectreNG variants out there, where details are not yet publicly known.
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.
Its 2018, entry level phones and $50 TV boxes come with 8x 64 bit cores. Not 2 cores split into 4 threads, or 4 cores split into 8.
5 years ago, mainstream laptop was Core i3, 3217U with a cpu benchmark of 2300.
5 years later and the mainstream is Core i3-7100T with a cpu benchmark of 5080
5 years to only double performance, and then the increase comes from upping the clock speed (1.8Ghz vs 3.4 Ghz).
Meanwhile ARM sells tens of billions of processors, and Intel sells 15% of that number and dropping. Intel tries to protect its profit on ever lower and lower numbers of sales.
I'm reminded of IBM and its slow processors that cost $millions each, sold to customers who are the final lockins to their mainframes. That is Intel's future unless it starts to take competition seriously.
In a couple of places, the summary says support is being removed for hyperthreading. Elsewhere, it says an option is being added to OpenBSD to disable hyperthreading. These are very different things. I think it's prudent to allow the user the option to disable hyperthreading and perhaps to turn it off by default. The premise of OpenBSD is to be secure by default, so it's logical to disable hyperthreading unless the user turns it on. However, hyperthreading provides a substantial performance boost, so I don't agree with altogether removing support for it. That seems unnecessary and would give the user the options of either switching to another OS or taking a significant performance hit. It's more logical to allow the feature to be disabled by the OS, which is what I think OpenBSD is actually doing. It may even be logical and in line with the OpenBSD philosophy to disable hyperthreading by default.
The feature has been added to all Intel CPUs released since 2002
No it hasn't. HT is a differentiating feature between many of their product lineups.
..obviously the answer is YES.
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.
Um nope.
If you bothered to follow the link to Hyper-threading (HT) it says:
Intel® Hyper-Threading Technology (Intel® HT Technology) uses processor resources more efficiently, enabling multiple threads to run on each core
That's parallel operations per-core not parallel operations on different cores. One is HT, the other is SMT.
Different things.
"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 some of the recent vulnerabilities, the OpenBSD team, unlike other OS vendors was not informed in advance. So even when one assumes that there is a SpectreNG-variant that uses Hyperthreading, it is not so obvious that it is known to the OpenBSD developers.
On the other hand, knowing that there are more SpectreNG-variants, and not having been informed about the details might make the OpenBSD devlopers even more cautious about any hardware feature that looks suspicious.
The general idea behind these flaws is that one process can flush the cache that another process is using, and testing whether the flushed area is free. By measuring the amount of time these flush/reload operations take, one can determine most or all of the bits of the secret signing exponent or private key when it's being used in the square-and-multiply algorithm, for example.
The attacker needs to be on the same machine. However, the main point is that any attacker program doesn't need elevated priveleges to carry out the timing attack since the attacking process will have access to the same cache that a sensitive program is using. Therefore, any seemingly legitimate program that is currently running could have this attack embedded inside it.
An attack on GnuPG can be mitigated by modifying the square and multiply algorithm, for example, so that it always multiplies. However, cryptographic attacks aren't the only problem - potentially, timing attacks can be carried out on all kinds of software as they slowly leak data.
"What lies behind us, and what lies before us are tiny matters compared to what lies within us." Ralph Waldo Emerson
1. You define a super high spec above the actual real world market for PC games, e.g. Fortnite's actual recommended spec (not minimum) is this:
Fortnite: Recommended requirement Core i5 2.8 Ghz 4GB Intel HD 4000 Nvidia GTX 660 or AMD Radeon HD 7870 equivalent DX11 GP.
2. You ignore the mainstream market for games which is Android phones on mobile, and Nintendo Switch on consoles, both of which are ARM based.
3. My original comment pointed out Intel's shortcomings on processor speed and core count, and you answered with a "well GPU's are faster" and "Well Windows 10". i.e. you didn't address Intel's piss poor chips, preferring instead to cite faster gaming GPUs and Windows 10 compatibility.
I went out to *BSD's grave on Decoration Day. The old forgotten cemetery is by the dark woods beyond the edge of town. There within olfactory distance of the municipal treatment plant you will find *BSD's final resting place.
*BSD's tombstone was shrouded by thick mosses and knots of noxious ivy. I gently pulled aside the tangled twists of thorns, and cleaned the decaying marker the best I could. My melancholy thoughts pondered that this indeed was *BSD's figurative charnel house of which so many have plaintively spoken.
Nothing is so pitiful as an untended grave, a loved one now forgotten. The short sad life of this doomed and fated OS makes us realize that there but for the grace of God go all of us.
I planted some wilting marigolds which I had found discarded behind Bud's Garden Center. By some miracle perhaps they will take root and bring a modicum of cheer to BSD's God forsaken plot. My fervent hope is that the torpid colored boy who carelessly mows the cemetery doesn't slice them down, inadvertently mirroring *BSD's own doomed encounter with death's irresistible scythe.
Funny how things work out. Linux, that brilliant novam stellam, now runs the Internet and the world's fastest computers, while *BSD lies moldering within its forgotten crypt. Let the barren silence of *BSD's tomb be a mute reminder that hubris and braggadocio were no defense on that woeful day when the Angel of Death's bleak umbra was cast upon *BSD.
What about AMD's SMT implementation in their new CPU's?
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.
i5, for example, don't have hyperthreading.
Oh, man... Just say it! Windows is the most secure software out there as a consequence.
Per Wikipedia:
" It first appeared in February 2002 on Xeon server processors and in November 2002 on Pentium 4 desktop CPUs"
None of the Pentium M(2003), Core(2005), or Core2s(2006) had it. It was reintroduced in the i7 around 2008, and most Celeron, Pentium, & Desktop i5s don't have it. And the Sivermont Atoms removed it as well.
Where is the story here?
OpenBSD has said hyperthreading was a security risk even back in the Pentium 4 days when Intel first released hyperthreading. They have always distrusted it.
Suck it, Intel.
Not true, Big Little was replaced by Big Little *MP* back in 2013. All 8 cores run.
https://www.youtube.com/watch?v=fLrSTJECVaU
I can see that with 2 processes running on a CPU, process A could indirectly get information about process B (e.g. crypto key) via timing attack.
But if a CPU has 10 processes, I fail to understand how a timing attack could ever work.
How could process A use timing attack, when the cpu time could have been allocated to process B, C, D or E etc?
So to me, it seems these timing attacks are a storm in a tea-cup. Is it a hyped up problem that really is unusable in the real world (most computers don't have exactly 2 processes running)?
Unicode has been readable for almost 30 years. Perhaps you can make a cheat sheet for the admins to enable UTF-8 or something, which is even the default on the Raspberry Pi I just setup.
Would it be feasible to give processes pages of cache? Use a heuristic to determine how many pages a process should be allowed, and isolate them from each other? Thus a process can only evict data from its own portion of the cache, and cannot access/influence/determine via timing attack what other processes on the system are doing?
Oops, too late: ENIO Ethernet, Audio, and Keyboard adapter for NES
Look where it got us...
"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." . This is an incorrect statement.
HT is not SMT. HT is one core running two threads in parallel by providing a perception of multiple logical cores to the OS.
Another proponent of the USA PATRIOT Act? (https://en.wikipedia.org/wiki/Patriot_Act)
This is absolutely going to kill my 1% lows in Tuxracer.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
4K? 8K? Those are Atari 2600 numbers. Activision's River Raid was 4K.
By the time ARM gaming devices became mainstream (Game Boy Advance, 2001), games' data sizes had ballooned in size to 4096K or bigger. Even the "multiboot" games, which you could download to the system's RAM through the serial link without needing a cartridge, were up to 256K.
The days of hyperthreading only achieving 0-10% gains are long gone. That was true of Intel's first HT implementation, which they withdrew from the marketplace. I forget the initial, widely panned release but it was a LONG time ago. Like more than 10 years ago, and could be close to 20 years ago.
When Intel brought back HT they consistently hit 10-30%, with an average of about 20% performance gains.
You might want to update both your information and your attitude.
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.
Thanks, I was reading the comments and had forgotten about this nugget of lazy falsehood.
It's more than segmentation, there also were entire architectures that don't support it altogether. Core 2 Duo and Core 2 Quad to start with (and Pentium M, Core Duo)
The first few gens of Atom had Hyperthreading, but everything modern since Bay Trail (22nm) are quad core without Hyperthreading (or dual core : two cores are disabled). This includes every Celeron/Pentium branded Atom. Plus the 8-core Atom servers (R.I.P. - these sadly have a defect that kills them in a few years ; I think there's new 16-core server Atom in the pipes)
Disabling hyperthreading does EXACTLY JACK SHIT. The same flaw applied to multiple logical cores very easily applies to multiple physical cores and multi-socket systems.
Every intel CPU appears to still be vulnerable as shit. Tested on my i3-7320 system and my multi-socket E5-2650 system under Windows. If OpenBSD wants to be 'secure' they need to only allow one logical core, period, and ignore all the rest. That's the only way to mitigate this problem.
The OpenBSD devs just showed a huge lack of logical thinking and knowledge of hardware configurations.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Not going to let them take my HT.
They should disable their own operating system too. I have heard that it has had vulnerabilities in the past and likely has others not detected yet. Better to be safe than sorry.
It would be nice if the browser could signal the scheduler that it launched a new tab as an untrusted process, causing the kernel to sanitize caches before and after its future time slices (in addition to any sandboxing the browser parent process and the OS were already doing).
It might also make sense if only processes with the same UID could run on different SMT threads on the same core, rather than just turning them off completely.
Can anybody point to a verified report of successful Meltdown and Spectre exploits in the wild?
So far, it seems to be just a theoretical security exploit.
I have no problem with OpenBSD locking it down, it is what they do and it is what the people who are drawn to OpenBSD expect.
My personal belief is that useful constructs like speculative execution and hyper threading are being abandoned for questionable reasons.
Average Intelligence is a Scary Thing
... but not it's correct implementation from the DEC Alpha processor. At least the AMD implementation is closer to being correct.
The feature has been added to all Intel CPUs released since 2002 and has come enabled by default.
My Intel Pentium Anniversary Edition CPUs and Intel Atom CPUs are proof that this carelessly researched statement is simply dead wrong.
Kriston