[Xen-devel] [PATCH v2] x86/HVM: don't give the wrong impression of WRMSR succeeding

["Jan Beulich" <JBeulich@xxxxxxxx>]

... for non-existent MSRs: wrmsr_hypervisor_regs()'s comment clearly
says that the function returns 0 for unrecognized MSRs, so
{svm,vmx}_msr_write_intercept() should not convert this into success. We
don't want to unconditionally fail the access though, as we can't be
certain the list of handled MSRs is complete enough for the guest types
we care about, so instead mirror what we do on the read paths and probe
the MSR to decide whether to raise #GP.

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
---
v2: Probe MSR just like is already done on read paths.

--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2125,6 +2125,13 @@ static int svm_msr_write_intercept(unsig
             result = X86EMUL_RETRY;
             break;
         case 0:
+            /*
+             * Match up with the RDMSR side for now; ultimately this entire
+             * case block should go away.
+             */
+            if ( rdmsr_safe(msr, msr_content) == 0 )
+                break;
+            goto gpf;
         case 1:
             break;
         default:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3161,6 +3161,13 @@ static int vmx_msr_write_intercept(unsig
                 case -ERESTART:
                     return X86EMUL_RETRY;
                 case 0:
+                    /*
+                     * Match up with the RDMSR side for now; ultimately this
+                     * entire case block should go away.
+                     */
+                    if ( rdmsr_safe(msr, msr_content) == 0 )
+                        break;
+                    goto gp_fault;
                 case 1:
                     break;
                 default:




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