[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] x86: ignore guest microcode loading attempts
On 15/03/18 11:36, Jan Beulich wrote: >>>> On 15.03.18 at 12:14, <andrew.cooper3@xxxxxxxxxx> wrote: >> On 15/03/18 11:09, Jan Beulich wrote: >>> The respective MSRs are write-only, and hence attempts by guests to >>> write to these are - as of 1f1d183d49 ("x86/HVM: don't give the wrong >>> impression of WRMSR succeeding") no longer ignored. Restore original >>> behavior for the two affected MSRs. >>> >>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> >>> --- >>> v2: Add comments. >>> --- >>> While what is being logged for the current osstest failures on the 4.7 >>> and 4.9 branches doesn't fully prove this to be the problem, RCX holding >>> 0x79 and there being a recorded hypervisor level #GP recovery >>> immediately before the guest triple fault is sufficient indication imo. >>> What I'm unsure about is whether we want to ignore such writes also for >>> PV guests. If not, at least the WRMSR change would need to move into >>> hvm/hvm.c. >> Sorry - I've raced with v2 of your patch. The PV side currently always >> yields #GP, because we have a read_safe() check on the wrmsr side. With >> that behaviour retained (i.e. with !is_pv_domain() checks in the hunks >> below), Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> > Just to be sure we're on the same page (as the ! above is not what > I've meant to do), this is the hunk in question: LGTM. Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> > > @@ -200,6 +202,28 @@ int guest_wrmsr(struct vcpu *v, uint32_t > /* Read-only */ > goto gp_fault; > > + case MSR_AMD_PATCHLOADER: > + /* > + * See note on MSR_IA32_UCODE_WRITE below, which may or may not apply > + * to AMD CPUs as well (at least the architectural/CPUID part does). > + */ > + if ( is_pv_domain(d) || > + d->arch.cpuid->x86_vendor != X86_VENDOR_AMD ) > + goto gp_fault; > + break; > + > + case MSR_IA32_UCODE_WRITE: > + /* > + * Some versions of Windows at least on certain hardware try to load > + * microcode before setting up an IDT. Therefore we must not inject > #GP > + * for such attempts. Also the MSR is architectural and not qualified > + * by any CPUID bit. > + */ > + if ( is_pv_domain(d) || > + d->arch.cpuid->x86_vendor != X86_VENDOR_INTEL ) > + goto gp_fault; > + break; > + > case MSR_SPEC_CTRL: > if ( !cp->feat.ibrsb ) > goto gp_fault; /* MSR available? */ > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |