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]

Date:	Wed, 3 Jun 2015 06:43:34 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...nel.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()

On Tue, Jun 2, 2015 at 11:20 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
> 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.

Yeah, you're probably right that we should look into at least having
the option to use the HPET.

That said, the fact that we can read the period from HPET_PERIOD does
*not* make me trust it all that much. I suspect that register is just
another "filled in by firmware" piece of data.

> Given that Windows relies on the
> HPET for timekeeping, it might get more attention than the PIT?

Does Windows actually do that? Becuase if so, that's just about the
strongest argument for HPET there is - it's likely to work, and the
frequency is likely to be correct.

We've had issues with HPET, but for calibration it might very well be
the right thing to do.

Does anybody know what the base oscillator for HPET tends to be? Also,
some googling shows a vmware paper that is not that impressed with the
HPET.

The good thing about the PIT is that it's just *specified* to be
driven off a real crystal running at a very fixed frequency. There's
no gray areas there. Sure, virtualization can screw it up (but will
likely screw up other higher-resolution clocks even more), and hw
designers can cause problems, but it's been pretty reliable.

(Yeah, the CMOS RTC clock should be too, as George Spelvin points out.
That might be worth looking at too).

                           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/