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

[Xen-devel] [PATCH] x86: ignore guest microcode loading attempts



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>
---
While what is being logged for the current osstest failure on the 4.7
branch (I have to admit that I don't understand why it's only that
branch which shows a regression) 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.

--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -147,6 +147,8 @@ int guest_rdmsr(const struct vcpu *v, ui
 
     switch ( msr )
     {
+    case MSR_AMD_PATCHLOADER:
+    case MSR_IA32_UCODE_WRITE:
     case MSR_PRED_CMD:
         /* Write-only */
         goto gp_fault;
@@ -200,6 +202,16 @@ int guest_wrmsr(struct vcpu *v, uint32_t
         /* Read-only */
         goto gp_fault;
 
+    case MSR_AMD_PATCHLOADER:
+        if ( d->arch.cpuid->x86_vendor != X86_VENDOR_AMD )
+            goto gp_fault;
+        break;
+
+    case MSR_IA32_UCODE_WRITE:
+        if ( 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

 


Rackspace

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