On 22/05/18 11:33, Jan Beulich wrote: > Other than in the feature sets, where we indeed want to offer the > feature even if not enumerated on hardware, we shouldn't dictate the > feature being available if tool stack or host admin have decided not > to expose it (for whatever [questionable?] reason). > > Signed-off-by: Jan Beulich <jbeul...@suse.com> > --- > This is effectively accompanying the discussion rooted at the 4.8/4.7 > patch at > https://lists.xenproject.org/archives/html/xen-devel/2018-05/msg01028.html > dealing with a feature leveling issue. > > --- a/xen/arch/x86/cpuid.c > +++ b/xen/arch/x86/cpuid.c > @@ -642,14 +642,6 @@ void recalculate_cpuid_policy(struct dom > recalculate_xstate(p); > recalculate_misc(p); > > - /* > - * Override STIBP to match IBRS. Guests can safely use STIBP > - * functionality on non-HT hardware, but can't necesserily protect > - * themselves from SP2/Spectre/Branch Target Injection if STIBP is hidden > - * on HT-capable hardware. > - */ > - p->feat.stibp = p->feat.ibrsb;
You've deleted a comment explaining why this is needed for safety reasons, without addressing the safety argument. Simply "because we shouldn't override the toolstack" isn't a reasonable argument. With the SP2 microcode, we have the following situations which can occur: * No mitigations * IBRSB visible * IBRSB and STIBP visible IBSRB enumerates MSR_SPEC_CTRL, MSR_SPEC_CTRL.IBRS, and MSR_PRED_CMD. STIBP enumerates MSR_SPEC_CTRL.STIBP SPEC_CTRL.STIBP is specified as usable (albeit, as a nop) even if STIBP isn't enumerated. This is deliberately and explicitly for heterogeneous migration scenarios, as it won't be a nop on other processors. In practice, this is so hypervisors can offer the feature unilaterally, and have it usable on non-HT hardware. However, to safely level it, dom0 needs to see it set in the information used to construct the guest policies. In principle, this should just be in the guest policy which needs adjusting. However, due to still not having got the CPUID policy improvements finished, dom0 is still excluded from cpuid faulting for the exclusive benefit of the CPUID logic in the domain builder, because it uses native CPUID to construct the guests CPUID policy. Therefore, dom0 is unable to create a safe CPUID policy for the guest, and Xen must override the setting. If you try and make this change, you will introduce a guest security issue on some hardware by hiding STIBP which is necessary for safety. ~Andrew
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
