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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan