Re: [PATCH for-4.17?] x86: support data operand independent timing mode

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Sep 30, 2022 at 05:24:21PM +0000, Andrew Cooper wrote:
> Hmm.  So yes, lets approach the problem from the other side, as "this bit 
> needs setting to unbreak crypto code".
> 
> On hardware supporting DOITM, where we do not advertise the feature to guests 
> (all guests right now), the guest kernel would conclude that it is safe, when 
> in fact it is not.
> 
> So Xen should set the bit behind the back of a guest which doesn't have the 
> DOITM enumeration presented (which is all guests right now).

Yes, makes sense.

> But I don't think we want any Kconfig about this, or a dedicated cmdline 
> option.  So how about this for a plan which avoids painting ourselves into a 
> corner.
> 
> 1) Extend cpuid= with a no-doitm option.  I know it's not actually a CPUID 
> enumeration, but MSR_ARCH_CAPS should have been CPUID data, and this is the 
> mechanism we have meaning "pretend this feature isn't enumerated".

Sounds fine. But I wonder if there is any plan for [virtualizing] other
MSR_ARCH_CAPS - will they be treated as cpuid too?

> 2) On boot, and S3 resume, if DOITM and availble, set invariant mode.

+1

> That should do as a stopgap for now that keeps software safe.
> 
> 
> Then, when we've got MSR_ARCH_CAPS working for guests, the internals of 
> MSR_UARCH_MISC_CTL change to being a context switched thing which, like 
> MSR_SPEC_CTRL, we have options for bits set behind the guest's back.  Then we 
> set DOITM behind the guests back if levelling causes the feature to be 
> hidden.  We do this for some bits already, and need to do so for more 
> controls too.
> 
> ~Andrew

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature