[Xen-devel] SVM/VMX and Interrupt Shadows

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

Hello,

All of this came about while reviewing some of Jans improvements to the
x86 instruction emulator.

It turns out that the XSA-156 / CVE-2015-8104 fix, c/s bd2239d9
"x86/HVM: always intercept #AC and #DB", introduced an awkward bug on
Intel hardware.

Executing a sti while singlestepping is active currently causes a
VMEntry failure, because the #DB is still intercepted, but on re-entry,
the sti interrupt shadow is still active and hardware complains about
invalid guest state.

Experimentally, on both Intel and AMD hardware, the mov_ss shadow
inhibits #DB and the VMexit caused by its interception, whereas the sti
shadow doesn't inhibit #DB.  Therefore, my planned fix for VT-x is to
unconditionally clobber the sti shadow if we intercept #DB.  I am also
looking to get the behaviour correct for all hardware, and from the
instruction emulator.

So my question to both AMD and Intel is how do the these shadow bits
actually function in real hardware? I can't find any useful information
in the manuals, other than rules about how to use the fields in the
VMCS/VMCB.

Additionally, Intel:

vmx_set_info_guest() clobbers the sti shadow if a debugger is attached,
citing a rule that eflags.TF may not be set alongside the sti shadow.  I
can't find any such rule in the list of vmentry checks, but then again I
can't find a rule which I have actually violated with the above
scenario.  Have I missed anything obvious?

AMD: Despite observably different behaviour, the VMCB only has a single
bit for shadowing.  Will the hardware mov_ss shadow always inhibit all
#DB activity, including instruction breakpoints on the following
instruction?  If not, I can't see a way to safely fix this.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel