linux-kernel - Re: [PATCH v2] x86: bring back rep movsq for user access on CPUs without ERMS

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: <CAGudoHH-KZcmTjPQihiZ3cAYQwyNhw4q2Yvdrxr-xKBp8nTwPw@mail.gmail.com>
Date:   Sun, 3 Sep 2023 23:06:14 +0200
From:   Mateusz Guzik <mjguzik@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        bp@...en8.de
Subject: Re: [PATCH v2] x86: bring back rep movsq for user access on CPUs
 without ERMS

On 9/3/23, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Sun, 3 Sept 2023 at 13:49, Mateusz Guzik <mjguzik@...il.com> wrote:
>>
>> It dodges lockref et al, but it does not dodge SMAP which accounts for
>> the difference.
>
> Yeah, just doing that "check if the name is empty" is not free. The
> CLAC/STAC overhead is real.
>
> I see no way of avoiding that cost, though - the only true fix is to
> fix the glibc braindamage.
>
> In fact, I suspect that my stupid patch is unacceptable exactly
> because it actually makes a *real* fstatat() with a real path much
> worse due to the "check if the path is empty".
>

I don't think it is *that* bad. I did a quick sanity check on that
front by rolling with bpftrace on cases which pass AT_EMPTY_PATH *and*
provide a path. Apart from my test prog which deliberately did that
nothing popped up in casual testing. But there is definitely funny
code out there which passes both not for testing purposes, so there is
that.

> We could possibly move that check into the getname() path, and at
> least avoid the extra overhead.
>

Complexity aside that would eat some of the win as kmalloc/kfree are
not particularly cheap, and I'm even ignoring the INIT_ON_ALLOC
problem.

So I would not go for it, but that's my $0,03.

That said, I'm going to engage glibc people to sort this out on their
end. Arguably this is something everyone will be able to backport to
their distro no matter how LTSy (not that I expect it to happen ;)).

-- 
Mateusz Guzik <mjguzik gmail.com>