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."
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
They don't do 'usable' as in 'hand holding'; but, while that imposes a nontrivial learning curve, it has the very refreshing effect of meaning that there is relatively little 'automagic' doing cryptic stuff when you aren't looking in order to try to make things Just Work. If you want something somewhere you will probably have to put it there; but if you put something somewhere it probably won't get moved unexpectedly.
Atuomagic has its place(the old OpenBSD installer's enthusiasm for not hiding details of disk partitioning was always sort of irksome without obvious benefit; and it has been dropped in newer versions); but (outside of substantially smaller embedded and educational OSes) OpenBSD does atypically well in giving you the ability to know what is going on, not just have a rough mental sketch of where the black boxes and here-be-dragons zones are. Makes it nice to work with after some time beating your head against automagic that isn't working for some reason and is brutally opaque about why.