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

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]