linux-kernel - Re: [PATCH 0/3] Improve TSC as a clocksource under VMware

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, 21 Oct 2008 21:27:47 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Alok Kataria <akataria@...are.com>
Cc:	Andi Kleen <andi@...stfloor.org>, "H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Daniel Hecht <dhecht@...are.com>
Subject: Re: [PATCH 0/3] Improve TSC as a clocksource under VMware

On Tue, Oct 21, 2008 at 12:10:36PM -0700, Alok Kataria wrote:
> On Tue, 2008-10-21 at 11:15 -0700, Andi Kleen wrote:
> > > FWIU from the code, even if  cpu A's TSC is just 1 tick behind that of
> > > cpu B, we increment the nr_wraps value.
> > > And the code expects that there are no wraps in TSC throughout the
> > > 20msec measurement window.
> > > So IMO its fairly easy to fail this test.
> > 
> > Ok I think it would be better to enlarge the margin then to fix your
> > issue.
> > 
> 
> Yeah, i thought about that, but given the different kinds of native
> hardware that we have i think coming up with values that would be safe
> for all the cases would be difficult. And given that nobody has
> complained about this on native until now, i would prefer not to change

It would certainly be the better solution (or trusting the CPUID bit)

Hypervisors are pretty popular these days and there are many different
flavours and if each of them adds their own detection code Linux will soon 
get very crowded. It's just a non scalable bad solution.

> the status quo. Apart from that, even on VMware virtualized environment
> there can different configurations where this margin keeps on varying,
> under different scenarios, f.e. under overcommitment and all. So i don't
> think that changing threshold values maybe safe for all cases. 

When the margin changes then it likely won't be good enough for
gettimeofday(). There are a couple of testers for monotonity around,
would such a system with shifting marging surive running them
for a few days?


> 
> I think going with ignoring this check for specific systems is the best
> way to go further. 

Disagree.


> I hope you also agree with the CONSTANT_TSC check.

Yes constant_tsc is good, although the question is how much sanity 
check is still needed. I suspect even with it some sanity check
will still make sense.

And the question is if your HV even sets the bit?
Also you would need to change the Linux code to check it on Intel too.

-Andi

-- 
ak@...ux.intel.com
--
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/