linux-kernel - Re: [GIT pull] x86/urgent for v5.9-rc2

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: <87ft8dqaxw.fsf@nanos.tec.linutronix.de>
Date:   Mon, 24 Aug 2020 00:00:59 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>
Subject: Re: [GIT pull] x86/urgent for v5.9-rc2

On Sun, Aug 23 2020 at 11:29, Linus Torvalds wrote:
> On Sun, Aug 23, 2020 at 1:26 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>>
>> Remove the RDPID optimization, which is not even
>> backed by numbers from the paranoid entry path instead.
>
> Ugh, that's sad. I'd expect the LSL to be quite a bit slower than the
> RDPID on raw hardware, since LSL has to go out to the GDT.

We asked for numbers several times but so far we got none and some quick
checks I did myself are in the noise.

> And I don't think we need the GDT for anything else normally, so it's
> not even going to be cached.

Who cares, really?

It's pretty irrelevant because the main source of horrors are in having
to run through _ALL_ registered NMI handlers. Why would you worry about
the extra cache miss? It gets worse when the NMI handler needs to access
the NMI cause register and that happens more often than you would expect
in the cases where it matters, e.g. high frequency PERF NMIs, due to the
well designed hardware mechanism.

OTOH, enforcing the writes on every VMENTER/EXIT is insanely expensive
compared to the maybe RDPID advantage.

While my general reasoning is that virtualization causes more problems
than it solves, in this particular case insisting on a few bare metal
cycles in paranoid entry would be beyond hypocritical.

> Oh well.

My summary would be less politically correct, so I just join the choir:

   Oh well ...

Thanks,

        tglx