Re: [PATCH] x86: enable Data Operand Independent Timing Mode

Marvin Häuser
2026-03-18T15:39:32Z

Hi all,

As I haven’t found any news on the list or the tree, I'd like to inquire whether
there’s been any updates on the situation.

> On 3. Feb 2023, at 17:25, Dave Hansen <dave.hansen@intel.com> wrote:
>
> There are some other crazier choices like adding ABI to toggle DOITM for
> userspace, but I'm not sure they're even worth discussing.

Sorry if I misunderstood something, but isn’t that basically the only effective
way to use DOITM? DDP is not active in kernel mode regardless of DOITM and the
FSFP documentation says that existing mitigations for SSB and such “usually”
will also be sufficient for FSFP. I assume in absence of KERNEL_SSBD, the other
existing mitigations would simply be augmented as necessary, rather than
enabling something alike KERNEL_FSFPD. But I may be totally mistaken here.
I further assume variable-latency instruction semantics still do not apply, so
to my understanding, FSFP is the only potential concern to the kernel, and it’s
not that bad.

Meanwhile, DDP is active in userspace and potentially violates the “no
secret-dependent memory accesses” constant-time programming rule at the
microarchitectural level. While real-world risk is up for debate, for truly
constant-time execution it must never trigger on memory that contains secrets.
To my knowledge, the only way to achieve this right now is to turn it off. The
Intel documentation also recommends against turning it off generally. So, either
there must be an opt-out per-process (and the processes should be mostly
isolated regarding computation on secrets, otherwise all other operations face
the performance penalty as well), or there must be a dynamic toggle like there
is for prctl() speculation control. As ARM has basically the same thing, I’m not
sure there’s much benefit in relaxing the semantics (but there might be in
making it accessible in userspace).

OT/Motivation: DDP has a rarely talked about implication from the prefetching
window. Namely, when accessing non-secret memory adjacent to secret memory, it
can activate on secret memory even when it is never accessed while DDP is
enabled. There are multiple solutions to this, e.g., to place guard pages around
secret memory and trust DDPs will fault and back off. Another way is to make
sure secret memory is never mapped while DDPs are active. I’m playing around
with this at the moment because unmapping secret memory also would mean that
mitigations like SLH only need to be applied to code that can execute while
secret memory is mapped. This can be achieved with pkeys, but it requires some
extra work to ensure no process’s secret memory pkey allows reads while DDPs are
on, even during context switches. Maybe more on that to come, maybe not, but I
wanted to provide my motivation in this. :)

> 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.

The Intel documentation seems to be fairly stable, so I assume not much happened
on the hardware/ISA side?

Thank you!

Best regards,
Marvin