diff options
author | Jan Beulich <jbeulich@suse.com> | 2013-04-18 16:23:07 +0200 |
---|---|---|
committer | Jan Beulich <jbeulich@suse.com> | 2013-04-18 16:23:07 +0200 |
commit | 584eb7c15e4c94baaba93468776572dd7373a33c (patch) | |
tree | f647c43dc022c026c810083d0fbe3d68906f222f /tools | |
parent | f4537b51116009bfb8359681a758ef5860cfd0db (diff) | |
download | xen-584eb7c15e4c94baaba93468776572dd7373a33c.tar.gz xen-584eb7c15e4c94baaba93468776572dd7373a33c.tar.bz2 xen-584eb7c15e4c94baaba93468776572dd7373a33c.zip |
x86: clear EFLAGS.NT in SYSENTER entry path
... as it causes problems if we happen to exit back via IRET: In the
course of trying to handle the fault, the hypervisor creates a stack
frame by hand, and uses PUSHFQ to set the respective EFLAGS field, but
expects to be able to IRET through that stack frame to the second
portion of the fixup code (which causes a #GP due to the stored EFLAGS
having NT set).
And even if this worked (e.g if we cleared NT in that path), it would
then (through the fail safe callback) cause a #GP in the guest with the
SYSENTER handler's first instruction as the source, which in turn would
allow guest user mode code to crash the guest kernel.
Inject a #GP on the fake (NULL) address of the SYSENTER instruction
instead, just like in the case where the guest kernel didn't register
a corresponding entry point.
On 32-bit we also need to make sure we clear SYSENTER_CS for all CPUs
(neither #RESET nor #INIT guarantee this).
This is CVE-2013-1917 / XSA-44.
Reported-by: Andrew Cooper <andrew.cooper3@citirx.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: fdac9515607b757c044e7ef0d61b1453ef999b08
master date: 2013-04-18 16:00:35 +0200
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions