linux-kernel - Re: [Patch] Skip cpu_calibrate for kernel running under hypervisors.

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, 17 Aug 2010 09:45:32 -0700
From:	Alok Kataria <akataria@...are.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Greg KH <gregkh@...e.de>, "greg@...ah.com" <greg@...ah.com>,
	"ksrinivasan@...ell.com" <ksrinivasan@...ell.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"borislav.petkov@....com" <borislav.petkov@....com>
Subject: Re: [Patch] Skip cpu_calibrate for kernel running under
	hypervisors.

Hi Borislav,

On Tue, 2010-08-17 at 00:05 -0700, Borislav Petkov wrote:
> From: "H. Peter Anvin" <hpa@...or.com>
> Date: Mon, Aug 16, 2010 at 11:30:48PM -0700
> 
> > On 08/16/2010 10:51 PM, Alok Kataria wrote:
> > >>
> > >> I'm somewhat reluctant to take this one, since it assumes all the
> > >> hypervisors act the same.  This seems rather inherently wrong.  In fact,
> > >> the whole statement is fishy as heck... instead of being dependent on
> > >> AMD and so on, 
> > > 
> > > The check about being on AMD is something that was already there. 
> > > 
> > 
> > I know it was... and calibrate_cpu() seems to be an AMD-specific
> > function, but that's rather crappy.  I'm thinking that perhaps we should
> > make it an x86_init function, then the AMD CPU detection can install it
> > and the vmware hypervisor detection can uninstall it.
> 
> Btw, can we revisit this AMD-specific issue? IIUC, Alok you're seeing
> a mismatch between the calibrated TSC value and the cpu frequency even
> on cpus which have the CONSTANT_TSC bit set, i.e. their TSC is counting
> with P0 frequency. Can you please elaborate more on what systems you're
> seeing this (cpu family, chipset, etc)?

We have seen these issues when running inside a Virtual Machine on
VMware's platform. Please look at the vmware_set_cpu_features function,
it relies on the hypervisor to provide a constant/reliable TSC. Though
still when running the kernel on virtual cpus, as compared to
running on physical cpus, the timing characteristics are different,
since virtual cpus have to time share physical cpus with each other,
which may result in errors during calibration. As a result its better to
get these values directly from the hypervisor rather than trying to
calibrate them.

And just to clarify, we have never seen this on a physical machine.

Thanks,
Alok


> 
> Thanks.
> 

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