Re: [PATCH 2/2] x86: Activate Data Operand Invariant Timing Mode by default

[Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>]

On 05/10/2022 13:09, Jan Beulich wrote:
> On 05.10.2022 12:20, Roger Pau Monné wrote:
>> On Tue, Oct 04, 2022 at 05:08:10PM +0100, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -209,6 +209,34 @@ void ctxt_switch_levelling(const struct vcpu *next)
>>>             alternative_vcall(ctxt_switch_masking, next);
>>>  }
>>>  
>>> +bool __ro_after_init opt_doitm = true;
>>> +
>>> +static void doitm_init(void)
>>> +{
>>> +    uint64_t val;
>>> +
>>> +    if ( !opt_doitm || !cpu_has_arch_caps )
>>> +        return;
>>> +
>>> +    rdmsrl(MSR_ARCH_CAPABILITIES, val);
>>> +    if ( !(val & ARCH_CAPS_DOITM) )
>>> +        return;
>>> +
>>> +    /*
>>> +     * We are currently unable to enumerate MSR_ARCH_CAPS to guest.  As a
>>> +     * consequence, guest kernels will believe they're safe even when they 
>>> are
>>> +     * not.
>>> +     *
>>> +     * Until we can enumerate DOITM properly for guests, set it 
>>> unilaterally.
>>> +     * This prevents otherwise-correct crypto from becoming vulnerable to
>>> +     * timing sidechannels.
>>> +     */
>>> +
>>> +    rdmsrl(MSR_UARCH_MISC_CTRL, val);
>>> +    val |= UARCH_CTRL_DOITM;
>>> +    wrmsrl(MSR_UARCH_MISC_CTRL, val);
>> Is it possible for the firmware to have enabled DOITM and Xen needing to
>> clear it if !opt_doitm?
> I think a firmware setup option is quite plausible to expect, such that
> safety can also be achieved underneath an unaware OS. Note how in my
> earlier patch I did specifically set the bit both ways, for this very
> reason.

Firmware is not likely to set it, but we should cope with the case when
we're somewhere along a kexec chain.

I'll adjust.

~Andrew