From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Differences on Intel and Amd Date: Mon, 21 Sep 2009 13:12:44 +0300 Message-ID: <4AB7519C.10307@redhat.com> References: <8d3051340909210305h5ddcfdc4xbb8d87b3f6bd3055@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org To: =?ISO-8859-1?Q?Alp=E1r_T=F6r=F6k?= Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57693 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751397AbZIUKMo (ORCPT ); Mon, 21 Sep 2009 06:12:44 -0400 In-Reply-To: <8d3051340909210305h5ddcfdc4xbb8d87b3f6bd3055@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 09/21/2009 01:05 PM, Alp=E1r T=F6r=F6k wrote: > Hi all, > > Sorry if this issues, or parts of this issue have been covered in > separate threads. > > We have an executable, of unknown origin, that is very likely to be > malicious. We use KVM ( version 78) for sand-boxing the execution of > such software. > Each time the Virtual Machine is started from a snapshot (with loadv= m > ), an executable is copied from a share and launched. > > Now the problem. We have both AMD and Intel machines. A snapshot > taken on Intel doesn't load on AMD and vice versa, so The snapshots > from which the VMs are > started are different. This executable, runs on the AMD machines, but > not on Intel. We concluded that the executable uses an undocumented > Windows API > function, and relies on a side-effect (a value placed in a register). > The value of this register differs from AMD to Intel. That is why it > shortly and silently terminates if ran on Intel. (by ran on Intel and > ran on AMD i mean of course a KVM VM on those platforms) > =20 On really new kvms this is no longer true, you can now load a snapshot=20 saved on a processor from another vendor. > The questions are: > Can a process within the VM find out the native processor type? > =20 Yes. The vendor ID is not virtualized (you can override it with=20 -cpu,vendor=3D to force virtualization). > Or can Windows XP find out the original processor type and behave d= ifferently? > =20 Yes, and it does. Windows (and Linux) use different system call=20 instructions depending on vendor. > Does this behavior make sense to you? > =20 Yes and no. It makes sense since the x86 instruction set is not truly=20 portable across vendors. It doesn't since it should. > Is it possible that the difference is not due to hardware > differences, but because of different snapshots, and the events that > occur before the snapshots, are different? > > =20 It is due to hardware differences. > We need to have consistent and repeatable results with thease > sand-boxed tests, that was what triggered the investigation in the > first place. > > =20 Try newer kvms. We now emulate the differences (with some performance=20 loss). --=20 error compiling committee.c: too many arguments to function