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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 9 Sep 2008 08:20:56 +0800
From:	Yan Li <elliot.li.tech@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Yan Li <elliot.li.tech@...il.com>, linux-kernel@...r.kernel.org,
	joerg.roedel@....com, rjmaomao@...il.com,
	Yinghai Lu <yhlu.kernel@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>, nancydreaming@...il.com
Subject: Re: [PATCH 1/2] VMware detection support for x86 and x86-64

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/