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.

As summed up in last week's testing article, recent and future Intel processors aren't guaranteed to be "constant time" with respect to their data operands unless a special model specific register flag is set. This caused concerns particularly around the cryptography code for Linux that there is no longer a guarantee of constant time and that the instruction execution time can vary depending upon the data operated on. The constant time execution is necessary to avoid possible side channel attacks. But in enabling the new Intel flag to ensure constant time, it comes with admitted performance implications.

The performance implications with current generation processors didn't end up being all that significant, but Intel documentation indicates that could increase in the future. With the Linux handling in it's current form is about always having the Data Operand Independent Timing Mode enabled. But now Intel is warning against such a move.

New Linux kernel mailing list posts from Intel engineers have shed further light on it. This post notes that any DOITM patches should wait before being mainlined:

We've been talking about this inside Intel. Suffice to say that DOITM was not designed to be turned on all the time. If software turns it on all the time, it won't accomplish what it was designed to do.

The _most_ likely thing that's going to happen is that DOITM gets redefined to be much more limited in scope. The current DOITM architecture is very broad, but the implementations have much more limited effects. This means that the architecture can probably be constrained and still match the hardware that's out there today. That's pure speculation (ha!) on my part.

I think we should hold off on merging any DOITM patches until the dust settles. As far as I know, there is no pressing practical reason to apply something urgently.

A follow-up post goes on to note:

It was designed with the idea that timing-sensitive and *ONLY* timing-sensitive code would be wrapped with DOITM. Wrapping that code would allow the rest of the system to safely operate with fancy new optimizations that exhibit data dependent timing.

But, first of all, that code isn't wrapped with DOITM-prodding APIs today. That model falls apart with current software on current DOITM implementations.

Second, we consider the kernel in general to be timing-sensitive enough that we want DOITM=1 behavior in the kernel.

Those lead software folks to set DOITM=1 on all the time. The fallout from that is that nobody will ever use those fancy new optimizations. If nobody can take advantage of them, silicon shouldn't be wasted on them in the first place.

Basically, DOITM was meant to open the door for adding fancy new optimizations. It's a failure if it doesn't do that.

Intel is expected to have more information to share on the matter in the coming days, but long story short, it looks like the proposed Linux kernel patches from last week will likely be tossed out / significantly reworked so this mode wouldn't always be active.