Anthony Liguori wrote:
> Yang, Sheng wrote:
>> From 9743b5299bae1779c2b893cbeb86122bcccb9b2d Mon Sep 17 00:00:00
>> 2001 
>> From: Sheng Yang <[EMAIL PROTECTED]>
>> Date: Wed, 2 Jan 2008 14:49:22 +0800
>> Subject: [PATCH] KVM: emulator: Only allow VMCALL/VMMCALL trapped by
>> #UD 
>> 
>> When executing a test program called "crashme", we found the KVM
>> guest 
>> cannot survived more than ten seconds, then encounterd kernel panic.
>> The basic concept of "crashme" is graduating random assembly code and
>> trying to execute them in a fork process.
>> 
>> After some fix on emulator valid 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), emulator would fetched the memory operand first rather than
>> judged the validity, and may encounter error there. 
>> 
> 
> Nice catch!
> 
> Regards,
> 
> Anthony Liguori
> 
Anthony:
        Actually I am wondering if the binary used for VMMCALL could be
assumed will never be used by Intel processor or vice versa.  BTW, what
is the nenefit to remove hypercall page, which provide more clean
approach IMO?
thx,eddie

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to