x86/svm: fix injection of software interrupts
authorAndrew Cooper <andrew.cooper3@citrix.com>
Tue, 22 Nov 2016 12:51:16 +0000 (13:51 +0100)
committerJan Beulich <jbeulich@suse.com>
Tue, 22 Nov 2016 12:51:16 +0000 (13:51 +0100)
commit920edccd41db6cb0145545afa1850edf5e7d098e
tree7e3f1574dc65bb4dd1fd1e4d28e676eec258cb12
parent255e8fe95f22ded5186fd75244ffcfb9d5dbc855
x86/svm: fix injection of software interrupts

The non-NextRip logic in c/s 36ebf14eb "x86/emulate: support for emulating
software event injection" was based on an older version of the AMD software
manual.  The manual was later corrected, following findings from that series.

I took the original wording of "not supported without NextRIP" to mean that
X86_EVENTTYPE_SW_INTERRUPT was not eligible for use.  It turns out that this
is not the case, and the new wording is clearer on the matter.

Despite testing the original patch series on non-NRip hardware, the
swint-emulation XTF test case focuses on the debug vectors; it never ended up
executing an `int $n` instruction for a vector which wasn't also an exception.

During a vmentry, the use of X86_EVENTTYPE_HW_EXCEPTION comes with a vector
check to ensure that it is only used with exception vectors.  Xen's use of
X86_EVENTTYPE_HW_EXCEPTION for `int $n` injection has always been buggy on AMD
hardware.

Fix this by always using X86_EVENTTYPE_SW_INTERRUPT.

Print and decode the eventinj information in svm_vmcb_dump(), as it has
several invalid combinations which cause vmentry failures.

This is CVE-2016-9378 / part of XSA-196.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
xen/arch/x86/hvm/svm/svm.c
xen/arch/x86/hvm/svm/svmdebug.c