Linux Developers Evaluating New "DOITM" Security Mitigation For Latest Intel CPUs

[phoronix]

Phoronix: Linux Developers Evaluating New "DOITM" Security Mitigation For Latest Intel CPUs

Last summer Intel published guidance around the Data Operand Independent Timing (DOIT) instruction mode that can be enabled with recent generations of Intel processors to ensure constant time execution for a subset of the Intel instruction set, which can be particularly important for cryptographic algorithms. Linux kernel developer discussions fizzled out last year over handling this DOIT functionality for what is described as a CPU vulnerability with recent Intel CPUs. However, now a Linux kernel patch from a Google developer would enable this change unconditionally for newer Intel CPUs but raises performance concerns.

https://www.phoronix.com/review/intel-doitm-linux

[bezirg]

Is AMD unaffected?

[bezirg]

Also, it looks like in case of ARM this mitigation is only enabled by default for kernel space and not foruserspace. Can something like this be achieved for the case of intel as well?

[Michael]

Is AMD unaffected?

There's been no published guidance or commentary that I've seen for AMD, just Intel and Arm.

[Developer12]

given the fact that cryptography can happen nearly anywhere in the kernel and userspace, and the fact that the entire kernel likely needs to be protected anyway.

Therefore, let's simply enable DOITM globally by default to fix this vulnerability. At most this gives up an "optimization" on the very latest CPUs, restoring the correct behavior from previous CPUs.

Surprisingly pragmatic, considering that for many spectre mitigations one must opt-in to protection. I can see lots of foot-guns, waiting for someone in the future to write some code and deploy it widely without considering they need to tag it as being security sensitive.

[Developer12]

Is AMD unaffected?

Most probably yes, until we hear otherwise.

They seem to be much more conservative about these kinds of optimizations, where as intel has bluntly stated that things are only going to get worse from here.

They seem hell-bent on pursuing optimizations that they know will leak data, then hefting the responsibility for turning them off onto the kernel and onto others. All while burning twice as much power as anyone else to get perhaps 10% more performance. One has to wonder where all of intel's talent went.

[archkde]

What about just enabling it unconditionally, and thereby pressuring Intel not to make the performance impact worse in upcoming generations?

[microcode]

People still so attached to AES and other primitives that make these problems a thing. Meanwhile there are primitives that are already constant time on these architectures...

[archkde]

People still so attached to AES and other primitives that make these problems a thing. Meanwhile there are primitives that are already constant time on these architectures...

AES (with AES-NI, without is obviously worse) and ARX designs are both affected the same way.

[Ironmask]

There has to be more lines of Intel mitigation code in the kernel than actual kernel code at this point.
There's already more articles about it than there are about core kernel patches.