linux-kernel - Re: [GIT PULL] timer fixes

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 Dec 2019 21:35:06 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Borislav Petkov <bp@...en8.de>
Subject: Re: [GIT PULL] timer fixes

On Tue, Dec 17, 2019 at 12:16:52PM -0800, Linus Torvalds wrote:
> On Tue, Dec 17, 2019 at 11:30 AM Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > What alternatives are there? That is, we normally only use HPET to
> > double check nobody messed up the TSC.
> 
> The thing is HPET seems to be _less_ reliable than the TSC we're
> checking these days.
> 
> If that's the only use-case for HPET, we should just stop doing it.
> 
> > We can't just blindly trust TSC across everything x86.
> 
> No, but we can trust it when it's a modern CPU.

Pray.. the TSC MSR is still writable from SMM, so BIOS monkeys could
still do what they've been doing for decades. Which is try and 'hide'
SMM latency by taking the TSC timestamp on SMM entry and writing the
timestamp back into the TSC MSR on exit.

Yes, ever since TSC_ADJUST we can better recover from it, but
we still need to first detect it went sideways and by then time has been
observed buggered and any recovery is basically too late :/

Granted, this is happening less (at least, I really do hope so).

Also, what consititutes a 'modern' CPU?

> The HPET seems to get disabled on all the modern platforms, why do we
> even have it enabled by default?

These new ones yeah, cuz they wrecked HPET in PC10 :/

> We should do the HPET cross-check only when we know the TSC might be
> unreliable, I suspect.

But how do we know? Ever since Nehalem TSC has basically been good
hardware wise -- there's a few exception on large (>4) socket machines,
but nobody has those anyway.

It has always been the BIOS messing it up. Now, the reason I think it
has gotten better is because Windows is now also relying on TSC (like
we've been doing forever).

Maybe I'm too scarred by too much TSC wreckage over the years...