Re: Differences on Intel and Amd

[Avi Kivity <avi@redhat.com>]

On 09/21/2009 01:05 PM, Alpár Török  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 loadvm
> ), 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)
>    

On really new kvms this is no longer true, you can now load a snapshot 
saved on a processor from another vendor.

> The questions are:
>   Can a process within the VM find out the native processor type?
>    

Yes.  The vendor ID is not virtualized (you can override it with 
-cpu,vendor= to force virtualization).

>   Or can Windows XP find out the original processor type and behave differently?
>    

Yes, and it does.  Windows (and Linux) use different system call 
instructions depending on vendor.

>   Does this behavior make sense to you?
>    

Yes and no.  It makes sense since the x86 instruction set is not truly 
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?
>
>    

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.
>
>    

Try newer kvms.  We now emulate the differences (with some performance 
loss).

-- 
error compiling committee.c: too many arguments to function