Intel's "DOITM" Security Feature Not Intended For Always-On Use, Linux Patches To Be Revised

[phoronix]

Phoronix: Intel's "DOITM" Security Feature Not Intended For Always-On Use, Linux Patches To Be Revised

Last week I wrote about Linux developers evaluating a new "DOITM" security mitigation for the latest Intel CPUs. While the cost for now of engaging the Data Operand Independent Timing Mode (DOITM) functionality is minimal, following internal Intel engineering discussions it looks like the Linux kernel patches will need to be re-worked with this functionality not intended to always be enabled...

https://www.phoronix.com/news/Intel-DOITM-Not-Always-On

[Developer12]

tough shit, intel.

these optimizations break fundamental assumptions that basically ALL security-relevant code relies upon. you cannot expect everyone on earth to go back and tag their code as doing security stuff or people WILL default to turning on the safe option all the time.

same goes for the additional security-relevant code written every day. it's simply too much work to coordinate everyone on this. the default must be safe.

if your mitigation isn't safe for all uses, then it will be disabled by default. it's too expensive in developer hours to identify every little spot where code is security sensitive

at best, if the optimizations are dangerous you might have people writing performance-sensitive code who bother to turn them on when it's safe since a lot of attention goes into optimization already.

[Vorpal]

A more sensible approach (to me at least) would have been opt in, per thread. A user space instruction to toggle this, then store the state in the register dump on context switches. Then code like openssl could get sane behaviour and some number crushing scientific software could go fast.

[andyprough]

Intel: "We wanted to sell you on our fake security mitigation for this non-existent threat, but we didn't think you were dumb enough to enable it all the time!"

Narrator: "They were up to the challenge. They were dumb enough."

[LightBit]

Even if this optimizations are worth it (currently I don't think so). This is really bad management by Intel. CPUs are already on market for few years and only now they say "by the way, we made some optimization and instructions are no longer constant-time".

When will all the code be fixed (set flag)?
How will you implement it high level languages?

After reading Intel's article it is still unclear to me which instructions and CPUs are affected.

[ssokolow]

And, yet again, more evidence that "Buy AMD" is the "better safe than sorry" option.

[piotrj3]

I suspect fancy optimalizations could be really fancy if intel is aproaching it this way.

I am rather optimistic here because such timing attacks might be really difficult (like spectre, attacks of this sort are really hard). So practical attack surface might be quite limited. You won't perform such timing attacks over network (too low precision), only realistic practical attack surface in my opinion are webrowsers that somehow could by javascript abuse it and maybe if you are using disk encryption - in that case disk encryption could warrant using doitm. But that would mean being forced to using doitm over quite limited amount of stuff.

Question (by far biggest one) is if DOITM will be needed in cloud aplication eg. you could steal data with it over virtual machine barriers.

[kylew77]

I wonder what OpenBSD will do? Theo is pretty big on security, I would bet he enables DOITM all the time in the name of security! Then tells Intel to go you know what themselves. He already made the difficult decision to disable SMT on all platforms in the name of security several years back now which proved to help mitigate many security concerns.

[Developer12]

I suspect fancy optimalizations could be really fancy if intel is aproaching it this way.

I am rather optimistic here because such timing attacks might be really difficult (like spectre, attacks of this sort are really hard). So practical attack surface might be quite limited. You won't perform such timing attacks over network (too low precision), only realistic practical attack surface in my opinion are webrowsers that somehow could by javascript abuse it and maybe if you are using disk encryption - in that case disk encryption could warrant using doitm. But that would mean being forced to using doitm over quite limited amount of stuff.

Question (by far biggest one) is if DOITM will be needed in cloud aplication eg. you could steal data with it over virtual machine barriers.

This basically boils down to "all the code on your computer must be trusted code"
That's fine in single user environments. Hell, it's fine on templeOS where there's no memory protection. It's not fine in a lot of real deployments.

There are plenty of machines out there with multiple users accessing them concurrently.

It is entirely possible to mount this kind of attack over the network and this has been done repeatedly with bad password and certificate checks that were not written to be constant time. Literally hundreds of CVEs.

Then there are multi-tenant VM environments. This side channel probably reveals a lot of information about the host or other tennants, just by asking them to perform operations that somehow touch confidential secrets. Try to SSH into another tennant's VM enough times and you could determine their password.

[pabs]

I am rather optimistic here because such timing attacks might be really difficult (like spectre, attacks of this sort are really hard).

The conceptual difficulty of an attack has very little bearing on the availability. People can (and do) create packages (metasploit modules, proof-of-concept scripts, etc) which make attacks accessible to a much wider audience.

You won't perform such timing attacks over network (too low precision)

Networks don't prevent timing side channel attacks; they only slow them down. Examples:

• Meltdown and Spectre were initially exploitable remotely
• Cache Timing Attacks on AES (PDF. Daniel J Bernstein, 2005): AES private key recovery over the network via a cache timing side channel attack. Note: This attack has been improved since the original 2005 paper, and most software-only AES implementations are vulnerable.