linux-kernel - Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit

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: <20150603062054.GA23303@gmail.com>
Date:	Wed, 3 Jun 2015 08:20:54 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Adrian Hunter <adrian.hunter@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Andi Kleen <ak@...ux.intel.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Len Brown <lenb@...nel.org>
Subject: Re: [PATCH RFC] x86, tsc: Allow for high latency in
 quick_pit_calibrate()

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Tue, Jun 2, 2015 at 12:33 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> >
> > Is there really no smarter way to figure out the TSC frequency on
> > modern systems?
> 
> Sadly, if there is, we have yet to find it.
> 
> I don't think the mentioned intel_pstate thing gets it right either. Yes, it 
> gets some "theoretical frequency", given the pstate and the scaling factor, but 
> that assumes the base clock (BCLK) is something trustworthy. That's a big 
> assumption, and I can pretty much guarantee it's not a valid assumption.
> 
> I'm sure that's the *common* case, but how much do you want to bet that some 
> motherboard makers noticed that they get good press from good benchmark numbers, 
> and that they can tweak BCLK a bit higher than the competition? "Oooh, 
> motherboard from Xyz is really good, it's 1% faster than the competition".
> 
> Or all those overclockers? Yes, some of them buy unlocked CPU's and leave BCLK 
> alone. Or maybe they do both. Or maybe they just buy locked CPU's and tweak 
> BCLK.
>
> The only *well-defined* clock in a modern PC seems to still remain the PIT. 
> [...]

and the HPET, which is pretty good as well, when available. In fact given that 
it's required to have a frequency of at least 10 MHz, and (unlike the PIT) has a 
pretty wide counter, it could be used for pretty accurate calibration as well that 
runs a lot shorter than PIT calibration.

HPETs have some quirks, and are sometimes emulated (on early hardware, when Window 
did not require HPET and the value of HPET was yet unclear?), but I'd say on 
modern x86 systems it ought to be a pretty good clock for calibration as well.

> [...] Yes, it's very sad.  But all the other clocks tend to be untrustworthy for 
> various reasons, like "frequency is stated in the ACPI tables", which we know is 
> basically just a fantasy that may be right *most* of the time, but I can almost 
> guarantee that some BIOS guys decided that they can get slightly better random 
> benchmark numbers by "tweaking" the truth a bit. It's the "BIOS version" of 
> overclocking by increasing BCLK - lie about the PM frequency, so that any 
> benchmark that times things that way will give better numbers..

So the HPET frequency comes straight from a hardware register, via:

        hpet_period = hpet_readl(HPET_PERIOD);

now you are right that the 'hardware' is in some cases is implemented via SMM 
virtualization - but so is the PIT I suspect. Given that Windows relies on the 
HPET for timekeeping, it might get more attention than the PIT?

> But pretty much nobody messes up the PIT. That will change, just because it's 
> clearly getting to the point where people are just emulating it, and it's 
> probably not going to be any more trustworthy than anything else.

So I think the reason why these tend to be real hardware most of the time is that 
both the PIT and the HPET are supposed to generate interrupts - which is not that 
easy to 'emulate' via SMM: you have to have a real irq-generating clock in the 
hardware _somewhere_, and that comes with counter and all, so not much left to 
emulate after that point.

What I think might happen is to emulate the PIT via HPET, the lower frequency 
clock with a higher frequency clock.

Thanks,

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