aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJan Beulich <jbeulich@suse.com>2012-07-26 16:57:18 +0100
committerJan Beulich <jbeulich@suse.com>2012-07-26 16:57:18 +0100
commite4c91a3f90d678490fb6c88e7e79142a4b18d854 (patch)
tree696e7f294d3ea16a466403c91c1243eb19be0585
parent00617e70904fee7b1f6efa99837d2c727e25756f (diff)
downloadxen-e4c91a3f90d678490fb6c88e7e79142a4b18d854.tar.gz
xen-e4c91a3f90d678490fb6c88e7e79142a4b18d854.tar.bz2
xen-e4c91a3f90d678490fb6c88e7e79142a4b18d854.zip
x86/hvm: don't leave emulator in inconsistent state
The fact that handle_mmio(), and thus the instruction emulator, is being run through twice for emulations that require involvement of the device model, allows for the second run to see a different guest state than the first one. Since only the MMIO-specific emulation routines update the vCPU's io_state, if they get invoked on the second pass, internal state (and particularly this variable) can be left in a state making successful emulation of a subsequent MMIO operation impossible. Consequently, whenever the emulator invocation returns without requesting a retry of the guest instruction, reset io_state. [ This is a security issue. XSA#10. -iwj ] Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com> xen-unstable changeset: 25682:ffcb24876b4f Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
-rw-r--r--xen/arch/x86/hvm/io.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 3c31a6d2e4..d59c237f78 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -176,6 +176,8 @@ int handle_mmio(void)
rc = hvm_emulate_one(&ctxt);
+ if ( rc != X86EMUL_RETRY )
+ curr->arch.hvm_vcpu.io_state = HVMIO_none;
if ( curr->arch.hvm_vcpu.io_state == HVMIO_awaiting_completion )
curr->arch.hvm_vcpu.io_state = HVMIO_handle_mmio_awaiting_completion;
else