(CC, sorry for resending, my client converted the e-mail to rich text by accident)
> On 18. Mar 2026, at 16:44, Dave Hansen <[email protected]> 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
