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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Oct 04, 2022 at 05:08:10PM +0100, Andrew Cooper wrote:
> Intel IceLake and later CPUs have microarchitectural behaviours which cause
> data-dependent timing behaviour.  This is not an issue for 99% of software,
> but it is a problem for cryptography routines.  On these CPUs, a new
> architectural feature, DOITM, was retrofitted in microcode.
> 
> For now, Xen can't enumerate DOITM to guest kernels; getting this working is
> still in progress.  The consequence is that guest kernels will incorrectly
> conclude that they are safe.
> 
> To maintain the safety of current software, activate DOITM unilaterally.  This
> will be relaxed in the future when we can enumerate the feature properly to
> guests.
> 
> As an emergency stopgap, this behaviour can be disabled by specifying
> `cpuid=no-doitm` on Xen's command line, but is not guaranteed ABI moving
> forward.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> CC: Wei Liu <wl@xxxxxxx>
> CC: Henry Wang <Henry.Wang@xxxxxxx>
> CC: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> CC: Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>
> ---
>  xen/arch/x86/cpu/common.c            | 29 +++++++++++++++++++++++++++++
>  xen/arch/x86/cpuid.c                 |  5 +++++
>  xen/arch/x86/include/asm/processor.h |  2 ++
>  xen/tools/gen-cpuid.py               |  2 ++
>  4 files changed, 38 insertions(+)
> 
> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
> index 0412dbc915e5..8c46a4db430a 100644
> --- 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?

Thanks, Roger.