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

Marvin Häuser
2026-03-18T20:17:14Z

(CC, sorry for resending, my client converted the e-mail to rich text by accident)

> On 18. Mar 2026, at 16:44, Dave Hansen <dave.hansen@intel.com> wrote:
>
> I'd summarize it like this: lots of meetings, no updates.
>
> IMNHO (and not speaking for my employer) DOITM itself is dead. There's
> almost no chance of Linux ever doing anything with the existing, public
> DOITM architecture.

Thanks for the quick update!

Well, I am not sure this changes much. So, DOITM has always been more or less
an alias for (DDPD_U | PSFD) (surprisingly, I don’t think the documentation
mentions FSFP is disabled in DOITM?) and will likely remain exactly that.

It might still make sense for the kernel to have some general DIT control.
Not only does ARM have DIT with a definition analogous to DOITM. The only
real-world implementation of ARM DIT I know of, Apple silicon, also toggles
their DDP alongside the core DIT semantics (starting with Apple M3) [1]. This
makes it roughly equivalent to Intel DOITM. Apple, for their implementation,
recommends toggling DIT for crypto code rather than per-process protection [2].
Of course, ARM’s doesn’t need a syscall.

So, to my understanding, DDP (and FSFP?) would still need to become “bugs” in
the kernel to be independent of SSBD (unsure there is a strong benefit, but
the documentation says there are alternative mitigations to SSB). The same is
true for MCDT, which appears to be an actual bug (userspace can apply
mitigations, so the kernel should just report whether the CPU is affected; or
is that not desired?). As Intel DOITM and Apple DIT have done, it still makes
sense to classify DDP under the DIT umbrella, because it’s the only “bug”
that leaks your secrets by design. So a general kernel DIT control should
toggle it, regardless of DOITM’s future. This would also allow adding DDP-like
optimizations with separate kill switches in the future, if necessary (though
that’s exactly the problem DOITM would solve).

OT: I think applications may benefit from an opt-out speculation mitigation
control. By that I don’t mean that every process has all mitigations applied
by default and has to proactively disable them, but that a process makes an
“apply sensible mitigations” syscall, agnostic to what these particular
mitigations are. If an application has manual hardening, it can then opt out
of a specific heavyweight kernel mitigation (e.g., it may be happy with lfence
over SSBD, or it may not be affected by a particular “bug” by design).
Of course, this can be implemented in userspace by having a shared library that
keeps up with in-kernel mitigations and applies them considering the
application-provided opt-out list. Otherwise, code remains vulnerable to novel
“bugs” until updated. I’m not sure whether an in-kernel mechanism or a shared
library would be the way to go. For mitigations that are low-risk but high-cost,
there could still be a separate opt-in. I just feel like the OS is the best
suited entity to make that decision when a new “bug” drops.

Best regards,
Marvin

[1] https://gofetch.fail/files/gofetch.pdf

[2] https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms