On 13.09.2022 16:22, Demi Marie Obenour wrote: > On Tue, Sep 06, 2022 at 10:01:00AM +0000, Andrew Cooper wrote: >> On 06/09/2022 10:52, Jan Beulich wrote: >>> On 02.09.2022 04:05, Demi Marie Obenour wrote: >>>> On Intel chips (Ice Lake and later) and ARM64, a bit needs to be set in >>>> a CPU register to enforce constant-time execution. Linux plans to set >>>> this bit by default; Xen should do the same. See >>>> https://lore.kernel.org/lkml/ywgcrqutxmx0w...@gmail.com/T/ for details. >>>> I recommend setting the bit unconditionally and ignoring guest attempts >>>> to change it. >>> I don't think we ought to set it by default; I can see reasons why kernels >>> may want to set it by default (providing a way to turn it off). In Xen >>> what I think we need is exposure of the bit to be guest-controllable. >> >> We absolutely should not have it set by default. It's a substantial >> overhead for something that is only applicable to code which otherwise >> crafted to be constant-time. > > Either Xen needs to set the bit by default, or guests need to both know > the bit needs to be set and be able set it. Otherwise code that *is* > intended to be constant-time has no way to protect itself. > >> As for why Xen doesn't enumerate/virtualise it, that's because >> virtualising MSR_ARCH_CAPS for guests is still not working yet, so the >> feature can't be enumerated yet even if we did support context switching it. > > Intel and ARM64 guarantee that CPUs that do not enumerate this flag > behave as if it is set unconditionally.
I'm not qualified to talk about the Arm side, but may I ask what you've derived this statement from for Intel? The doc page referenced by the link you did provide (still in context above) specifically further links to a page listing instruction with data operand independent timing. All other instructions, as I conclude, have variable timing unless the bit in ARCH_CAPS enumerates DOITM and then the new MSR bit (of the same name) is set. Jan
