A Detailed Explanation On Intel's DOIT Mode, Possible Options For Linux's Handling

[phoronix]

Phoronix: A Detailed Explanation On Intel's DOIT Mode, Possible Options For Linux's Handling

Following last week's article about Linux developers eyeing a new "DOITM" security mitigation for latest Intel CPUs based on guidance from Intel around Data Operand Independent Timing (DOIT) instructions and then it coming to light that the DOIT mode shouldn't always be on, a lengthier statement from one of Intel's Linux engineers has been published summing up the current beliefs and Linux kernel possibilities around DOIT(M)...

https://www.phoronix.com/news/Intel-DOIT-DOITM-Details

[Developer12]

Intel doesn't exactly have a good track record with judging that security stuff isn't busted.
I'm sure there are tons of security researchers tripping over each other right now as they race to publish various attacks.

Turn it the fuck off, look at safe ways in which to turn it on later. There's not even any real impact to disabling it.

The possibility of a bigger cost on future chips shouldn't matter. Those chips don't exist and handling can always be revisited.

[onlyLinuxLuvUBack]

itanic was unsinkable ship
pentium 4 not a winner
avx512 mess
screwed up optane
sgx unsecure
DOIT-m === this time for real

[archkde]

So if I understand it correctly, then the data-dependent timing, other than in the MXCSR cases, only applies to the CISC forms of the affected (i.e. almost all) instructions. This should be pretty good news, given that I assume almost all crypto code to use the register forms exclusively.

[willmore]

Wouldn't option 3 make the most sense? Implement the kernel changes to support it, but leave it off for now. If we end up needing it, it's a reboot away rather than a round of kernel patching and all the infrastructure delay that comes with that.