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
