linux-kernel - Re: [RFC patch 0/4] TSC calibration improvements

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]

Message-ID: <alpine.LFD.1.10.0809041447570.3117@nehalem.linux-foundation.org>
Date:	Thu, 4 Sep 2008 14:52:12 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alok Kataria <akataria@...are.com>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Arjan van de Veen <arjan@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [RFC patch 0/4] TSC calibration improvements

On Thu, 4 Sep 2008, Alok Kataria wrote:
> 
> The maximum count value that I see is 84.
> In one single reboot run, on an average in about 70 iterations the val
> returned from pit_expect_msb is > 50, and eventually we hit a condition
> where the value is < 50 and we bail out of the fast method.
> 
> So just to be on safer side can we be a little less generous and
> increase the threshold to somewhere around 75 from 50 ? Or is there a
> good reason not to ?

Why would you? 

The reason the single run completed successfully was apparently that no 
actual virtualization event triggered, so it actually accessed the 
hardware successfully and without any real slowdown.  As shown also by the 
fact that the actual frequency was correct at the end.

The ones that failed presumably all had interrupts that happened in the 
VM, which then immediately triggered the "uhhuh, there was a bump" thing.

IOW, the code worked correctly as designed. It's not a 
"anti-virtualization" feature per se, it's a "detect when virtualization 
screws up timing". When virtualization (or SMI etc) does _not_ screw up 
timing, it all works fine.

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