Right now, bad PV state is silently dropped and zeroed, while bad HVM state is
passed directly to hardware and can trigger VMEntry/VMRUN failures. e.g.
(XEN) d12v0 vmentry failure (reason 0x80000021): Invalid guest state (0)
...
(XEN) RFLAGS=0x00000002 (0x00000002) DR7 = 0x4000000000000001
Furthermore, prior to c/s
30f43f4aa81e ("x86: Reorganise and rename debug
register fields in struct vcpu") in Xen 4.11 where v->arch.dr6 was reduced in
width, the toolstack can cause a host crash by loading a bad %dr6 value on
VT-x hardware.
Reject any %dr6/7 values with upper bits set. For PV guests, also audit
%dr0..3 using the same logic as in set_debugreg() so they aren't silently
zeroed later in the function. Leave a comment behind explaing how %dr4/5
handling changed, and why they're ignored now.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
#endif
flags = c(flags);
+ if ( !compat )
+ {
+ if ( c(debugreg[6]) != (uint32_t)c(debugreg[6]) ||
+ c(debugreg[7]) != (uint32_t)c(debugreg[7]) )
+ return -EINVAL;
+ }
+
if ( is_pv_domain(d) )
{
+ for ( i = 0; i < ARRAY_SIZE(v->arch.dr); i++ )
+ if ( !access_ok(c(debugreg[i]), sizeof(long)) )
+ return -EINVAL;
+ /*
+ * Prior to Xen 4.11, dr5 was used to hold the emulated-only
+ * subset of dr7, and dr4 was unused.
+ *
+ * In Xen 4.11 and later, dr4/5 are written as zero, ignored for
+ * backwards compatibility, and dr7 emulation is handled
+ * internally.
+ */
+
if ( !compat )
{
if ( !is_canonical_address(c.nat->user_regs.rip) ||
return -EINVAL;
}
+ if ( ctxt.dr6 != (uint32_t)ctxt.dr6 ||
+ ctxt.dr7 != (uint32_t)ctxt.dr7 )
+ {
+ printk(XENLOG_G_ERR "%pv: HVM restore: bad DR6 %#"PRIx64" or DR7 %#"PRIx64"\n",
+ v, ctxt.dr6, ctxt.dr7);
+ return -EINVAL;
+ }
+
if ( ctxt.cr3 >> d->arch.cpuid->extd.maxphysaddr )
{
printk(XENLOG_G_ERR "HVM%d restore: bad CR3 %#" PRIx64 "\n",