Re: [PATCH 1/2] VMware detection support for x86 and x86-64

From: Yan Li
Date: Mon Sep 08 2008 - 20:21:21 EST


On Mon, Sep 08, 2008 at 04:04:23PM +0200, Ingo Molnar wrote:
> hm, i know it's not your fault as you just took this vmware code, but
> this is really not an acceptable method of detection. The above is
> totally unsafe to do on native hardware - we dont know whether there's
> anything on that port.

Yeah, I agree with you, it's a bad method. I just took it for granted
that vmware has done the necessary study and they knew what they were
doing. I have tested it on two boxes so I thought they were OK. Now I
agree it's a bit dangerous to put this in a general purpose kernel.

> vmware could have used one of the following methods to communicate to
> the guest kernel:
>
> - a CPUID and an MSR range - like a good virtual CPU should. That way
> even bootloaders could detect the presence of vmware.

They haven't done this. Per VMware's design, the cpuinfo in virtual
guest is identical to the underlying physical CPU. I guess they want
to send most of the code to run on underlying CPU directly and won't
have to do code mutation or emulation and get better performance.

> - or a PCI ID and a PCI driver like KVM does

Yup. But checking DMI would be easier for us.

> - or a system call hypercall gateway like Xen and KVM does

I think they didn't use this way cause VMware wanted it to be
OS-neutral.

> - or it could even have used a DMI signature of some sort

Some people are using this idea. From dmidcode, the VMware-related
parts are:

Handle 0x0001, DMI type 1, 25 bytes
System Information
Manufacturer: VMware, Inc.
Product Name: VMware Virtual Platform
Version: None
Serial Number: VMware-56 4d d2 bf 8d ea 6e ec-81 67 6d 50 42
72 07 46
UUID: 564DD2BF-8DEA-6EEC-8167-6D5042720746
Wake-up Type: Power Switch
............

Handle 0x001A, DMI type 10, 8 bytes
On Board Device 1 Information
Type: Video
Status: Disabled
Description: VMware SVGA II

I think it's pretty safe to assume all VMware products include
"[VM|vm]ware" in the manufacturer.

> but no, vmware had to use 30 year old unsafe ISA port magic...
>
> To add insult to injury that port is named 'backdoor' - very smart and
> confidence raising naming. Plus it does not even use some well-known PC
> port that is harmless to read - it has to be from the middle of the
> generic IO port resource range where a real PCI card could sit: 0x5658.
> Brilliant.
>
> is there really no vmware PCI ID to query? Could you post the lspci -v
> output of your vmware guest? We could add an early-quirk for one of the
> core vmware PCI devices (in case there are any - i bet there are).

VMware may change the PCI ID at their will so I prefer checking the
DMI since it's easier.

So if we ditched the official method we run the risk of some false
negatives. But checking the DMI manufacturer would be good enough.

--
Li, Yan

"Everything that is really great and inspiring is created by the
individual who can labor in freedom."
- Albert Einstein, in Out of My Later Years (1950)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/