[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |