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 <[email protected]> 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
