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:	Thu, 25 Sep 2008 11:29:27 +0800
From:	Yan Li <elliot.li.tech@...il.com>
To:	Greg KH <greg@...ah.com>
Cc:	Yan Li <elliot.li.tech@...il.com>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	joerg.roedel@....com, rjmaomao@...il.com,
	Yinghai Lu <yhlu.kernel@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>, nancydreaming@...il.com
Subject: Re: [PATCH 1/2] VMware guest detection for x86 and x86-64

On Wed, Sep 24, 2008 at 07:55:50PM -0700, Greg KH wrote:
> > Hi Greg,
> > 
> > For me this is used in the next patch (for mtrr/main.c) to suppress an
> > unnecessary warning when running as a VMware guest:
> > http://lkml.org/lkml/2008/9/24/144
> 
> But that has been stated it's a vmware bug, not a kernel bug :)

I think it's a common practice for VM to blank the MTRRs rather than a
bug. Many hypervisors (KVM, VMware, Virtual PC) are doing this since
long before. Therefore I think issuing a warning here complaining
about blank MTRRs are no use to VMware's users.

> > We already have code to suppress warning under KVM so the above patch
> > suppress warnings for VMware guest also.
> > 
> > H. Peter Anvin and Alok kataria are also proposing we may need a more
> > general approach for detecting hypervisors that can be used for some
> > other quirks.
> 
> Well, having a config option like this isn't the way to go as it will be
> forced on for all distros and users anyway.

My idea is that this should be included in all general purpose kernels
or the vendors may have to cope with flood questions about boot time
warnings when using under VMware/KVM/Virtual PC.  It's configurable so
good for vendors who wish to provide different kernels for using with
real-machines and VMs.

> A simple cpuid test is the easier way to do this, that's what the
> userspace tools do, if it's really needed in the kernel.  But hopefully,
> such things shouldn't be needed within the kernel as it's not Linux's
> fault that the hypervisor has bugs in it :)

A simple CPUID test is good but can't be used for VMware guest since
they just use underlying CPUID, so nothing special here can be
checked. That's why I'm using DMI.

> We wouldn't be wanting to work around bugs in Microsoft's hypervisor,
> would we?


-- 
Li, Yan
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ