From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: [PATCH] KVM: emulator: Only allow VMCALL/VMMCALL trapped by #UD Date: Sun, 06 Jan 2008 01:36:31 +0200 Message-ID: <4780147F.10708@qumranet.com> References: <200801040936.08670.sheng.yang@intel.com> <477D9610.4010605@codemonkey.ws> <10EA09EFD8728347A513008B6B0DA77A029B54D6@pdsmsx411.ccr.corp.intel.com> Reply-To: dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0914929706==" Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, "Liu, Eric E" To: "Dong, Eddie" Return-path: In-Reply-To: <10EA09EFD8728347A513008B6B0DA77A029B54D6-wq7ZOvIWXbNpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org This is a multi-part message in MIME format. --===============0914929706== Content-Type: multipart/alternative; boundary="------------000800090907030303090009" This is a multi-part message in MIME format. --------------000800090907030303090009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dong, Eddie wrote: > Anthony Liguori wrote: > >> Yang, Sheng wrote: >> >>> From 9743b5299bae1779c2b893cbeb86122bcccb9b2d Mon Sep 17 00:00:00 >>> 2001 >>> From: Sheng Yang >>> 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 > > The benefit is that one can migrate a running guest from Intel to Amd and vise versa without any effort of the guest/host knowing that. Can you offer other binary code for vmmcall that you're sure it won't be used in the future? Regards, Dor > ------------------------------------------------------------------------- > 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > --------------000800090907030303090009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dong, Eddie wrote: 
Anthony Liguori wrote:
  
Yang, Sheng wrote:
    
From 9743b5299bae1779c2b893cbeb86122bcccb9b2d Mon Sep 17 00:00:00
2001 
From: Sheng Yang <sheng.yang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
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
The benefit is that one can migrate a running guest from Intel to Amd and vise versa without
any effort  of the guest/host knowing that.
Can you offer other binary code for vmmcall that you're sure it won't be used in the future?
Regards,
Dor
-------------------------------------------------------------------------
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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

--------------000800090907030303090009-- --===============0914929706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- 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/ --===============0914929706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kvm-devel mailing list kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/kvm-devel --===============0914929706==--