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

[Xen-devel] [PATCH] x86/hvm: Disallow unknown MSR_EFER bits

It turns out that nothing ever prevented HVM guests from trying to set unknown
EFER bits.  Generally, this results in a vmentry failure.

For Intel hardware, all implemented bits are covered by the checks.

For AMD hardware, the only EFER bit which isn't covered by the checks is TCE
(which AFAICT is specific to AMD Fam15/16 hardware).  We never advertise TCE
in CPUID, but it isn't a security problem to have TCE unexpected enabled in
guest context.

Disallow the setting of bits outside of the EFER_KNOWN_MASK, which prevents
any vmentry failures for guests, yielding #GP instead.

Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
CC: Jan Beulich <JBeulich@xxxxxxxx>
CC: Wei Liu <wei.liu2@xxxxxxxxxx>
CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
CC: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>

Note: On AMD hardware, bits 7:1 are Reserved write-discard rather than
yielding #GP.  Implementing this doesn't seem worthwhile (no software will try
to set these bits, because they are strictly reserved on Intel hardware), and
would require rather more complicated changes to hvm_efer_valid() to feed back
a modified efer value.
 xen/arch/x86/hvm/hvm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 1816faa..c099c61 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -907,6 +907,9 @@ const char *hvm_efer_valid(const struct vcpu *v, uint64_t 
         p = &host_cpuid_policy;
+    if ( value & ~EFER_KNOWN_MASK )
+        return "Unknown bits set";
     if ( (value & EFER_SCE) && !p->extd.syscall )
         return "SCE without feature";

Xen-devel mailing list



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