aboutsummaryrefslogtreecommitdiff
path: root/samples
diff options
context:
space:
mode:
authorSheng Yang <sheng.yang@intel.com>2008-01-02 14:49:22 +0800
committerAvi Kivity <avi@qumranet.com>2008-01-30 18:01:21 +0200
commit571008daccc17c03ccec810922c2bcaed86b15c1 (patch)
treefa748f57d24dae69456e12c989d0f71c1a0caaa5 /samples
parent5882842f9b86179e1fe2e17e35e0e46a268d04e4 (diff)
KVM: x86 emulator: Only allow VMCALL/VMMCALL trapped by #UD
When executing a test program called "crashme", we found the KVM guest cannot survive more than ten seconds, then encounterd kernel panic. The basic concept of "crashme" is generating random assembly code and trying to execute it. After some fixes on emulator insn validity judgment, we found it's hard to get the current emulator handle the invalid instructions correctly, for the #UD trap for hypercall patching caused troubles. The problem is, if the opcode itself was OK, but combination of opcode and modrm_reg was invalid, and one operand of the opcode was memory (SrcMem or DstMem), the emulator will fetch the memory operand first rather than checking the validity, and may encounter an error there. For example, ".byte 0xfe, 0x34, 0xcd" has this problem. In the patch, we simply check that if the invalid opcode wasn't vmcall/vmmcall, then return from emulate_instruction() and inject a #UD to guest. With the patch, the guest had been running for more than 12 hours. Signed-off-by: Feng (Eric) Liu <eric.e.liu@intel.com> Signed-off-by: Sheng Yang <sheng.yang@intel.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
Diffstat (limited to 'samples')
0 files changed, 0 insertions, 0 deletions