[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v8 11/17] x86: Protect unaware domains from meddling hyperthreads



>>> On 12.01.18 at 19:01, <andrew.cooper3@xxxxxxxxxx> wrote:
> --- a/xen/include/asm-x86/spec_ctrl.h
> +++ b/xen/include/asm-x86/spec_ctrl.h
> @@ -20,8 +20,29 @@
>  #ifndef __X86_SPEC_CTRL_H__
>  #define __X86_SPEC_CTRL_H__
>  
> +#include <xen/sched.h>
> +
>  void init_speculation_mitigations(void);
>  
> +/*
> + * For guests which know about IBRS but are not told about STIBP running on
> + * hardware supporting hyperthreading, the guest doesn't know to protect
> + * itself fully.  (Such a guest won't be permitted direct access to the MSR.)
> + * Have Xen fill in the gaps, so an unaware guest can't be interfered with by
> + * a meddling guest on an adjacent hyperthread.
> + */
> +static inline unsigned int spec_ctrl_host_val(const struct domain *d,
> +                                              unsigned int guest_val)
> +{
> +    const struct cpuid_policy *cp = d->arch.cpuid;
> +
> +    if ( !cp->feat.stibp && cpu_has_stibp &&
> +         !(guest_val & (SPEC_CTRL_IBRS | SPEC_CTRL_STIBP)) )
> +        return SPEC_CTRL_STIBP;
> +    else
> +        return guest_val;
> +}

The comment's "won't be permitted direct access" can be verified
by looking at patch 10, but where's the HT dependency here (or
in another patch)? For now it looks to me as if you enabled this
behind-the-back protection even in the non-HT case.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.