A Detailed Explanation On Intel's DOIT Mode, Possible Options For Linux's Handling
As explained in the earlier Phoronix articles on the matter, based on guidance published last year by Intel around DOIT, 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 Intel processors didn't end up being all that significant from the initial testing I carried out, 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 then coming to light was the recommendation it not always be on.
DOITM mitigation with currently out-of-tree Linux kernel patch that sparked this recent discussion over the Intel DOIT instructions.
Longtime Intel Linux engineer Dave Hansen provided a lengthier LKML post about this functionality following various internal discussions at the company. The lengthy public explanation and extra insight was published to the kernel mailing list. For your convenience it's embedded below.
"This is an attempt to make sure that everyone that is concerned about DOITM behavior has all the same information as Intel folks before we make a decision about a kernel implementation.
Here we go...
The execution latency of the DOIT instructions does not depend on the value of data operands on all currently-supported Intel processors. This includes all processors that enumerate DOITM support. There are no plans for any processors where this behavior would change, despite the DOITM architecture theoretically allowing it.
So, what's the point of DOITM in the first place? Fixed execution latency does not mean that programs as a whole will have constant overall latency. DOITM currently affects features which do not affect execution latency but may, for instance, affect overall program latency due to side-effects of prefetching on the cache. Even with fixed instruction execution latency, these side-effects can matter especially to the paranoid.
Today, those affected features are:
* Data Dependent Prefetchers (DDP)
* Some Fast Store Forwarding Predictors (FSFP).
There are existing controls for those features, including spec_store_bypass_disable=. Some paranoid software may already have mitigations in place that are a superset of DOITM. In addition, both DDP and FSFP were also designed to limit nastiness when crossing privilege boundaries. Please see the linked docs for more details.
That's basically the Intel side of things. Everyone else should have all the background that I have. Now back to maintainer mode...
So, in short, I don't think everyone's crypto libraries are busted today when DOITM=0. I don't think they're going to _become_ busted any time soon.
Where do we go from here? There are a few choices:
1. Apply the patch in this thread, set DOITM=1 always. Today, this reduces exposure to DDP and FSFP, but probably only for userspace. It reduces exposure to any future predictors under the DOITM umbrella and also from Intel changing its mind.
2. Ignore DOITM, leave it to the hardware default of DOITM=0. Today, this probably just steers folks to using relatively heavyweight mitigations (like SSBD) if they want DDP/FSFP disabled. It also leaves Linux exposed to Intel changing its mind on its future plans.
3. Apply the patch in this thread, but leave DOITM=0 as the default. This lets folks enable DOITM on a moment's notice if the need arises.
There are some other crazier choices like adding ABI to toggle DOITM for userspace, but I'm not sure they're even worth discussing.
#1 is obviously the only way to go if the DOITM architecture remains as-is. There is talk of making changes, like completely removing the idea of variable execution latency. But that's a slow process and would be a non-starter if *anyone* (like other OSes) is depending on the existing DOITM definition.
My inclination is to wait a couple of weeks to see which way DOITM is headed and if the definition is likely to get changed. Does anyone feel any greater sense of urgency?"
At least this clears things up and is reassuring that existing crypto code on the latest Intel CPUs aren't "busted" without the Data Operand Independent Timing Mode (DOITM) enablement. We'll see though in the weeks ahead ultimately what the upstream Linux kernel developers decide to do about this Intel security feature/mitigation.
4 Comments
