linux-kernel - Re: [PATCH v3 2/2] vfs: avoid duplicating creds in faccessat if possible

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:   Fri, 3 Mar 2023 20:37:02 +0100
From:   Mateusz Guzik <mjguzik@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Alexander Potapenko <glider@...gle.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Kees Cook <keescook@...omium.org>,
        Eric Biggers <ebiggers@...gle.com>,
        Christian Brauner <brauner@...nel.org>, serge@...lyn.com,
        paul@...l-moore.com, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH v3 2/2] vfs: avoid duplicating creds in faccessat if possible

On 3/3/23, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Fri, Mar 3, 2023 at 9:39 AM Mateusz Guzik <mjguzik@...il.com> wrote:
>>
>> So the key is: memset is underperforming at least on x86-64 for
>> certain sizes and the init-on-alloc thingy makes it used significantly
>> more, exacerbating the problem
>
> One reason that the kernel memset isn't as optimized as memcpy, is
> simply because under normal circumstances it shouldn't be *used* that
> much outside of page clearing and constant-sized structure
> initialization.
>

I mentioned in the previous e-mail that memset is used a lot even
without the problematic opt and even have shown size distribution of
what's getting passed there.

You made me curious how usage compares to memcpy, so I checked 'make'
in kernel dir once again.

I stress the init-on-alloc opt is *OFF*:
# CONFIG_INIT_ON_ALLOC_DEFAULT_ON is not set
# CONFIG_INIT_ON_FREE_DEFAULT_ON is not set

# bpftrace -e 'kprobe:memset,kprobe:memcpy { @[probe] = count(); }'
[snip]
@[kprobe:memcpy]: 6948498
@[kprobe:memset]: 36150671

iow memset is used about 7 times as much as memcpy when building the
kernel. If it matters I'm building on top of
2eb29d59ddf02e39774abfb60b2030b0b7e27c1f (reasonably fresh master).

> So this is literally a problem with pointless automated memset,
> introduced by that hardening option. And hardening people generally
> simply don't care about performance, and the people who _do _care
> about performance usually don't enable the known-expensive crazy
> stuff.
>
> Honestly, I think the INIT_ONCE stuff is actively detrimental, and
> only hides issues (and in this case adds its own). So I can't but help
> to say "don't do that then". I think it's literally stupid to clear
> allocations by default.
>

Questioning usability of the entire thing was on the menu in what I
intended to write, but I did not read entire public discussion so
perhaps I missed a crucial insight.

> I'm not opposed to improving memset, but honestly, if the argument is
> based on the stupid hardening behavior, I really think *that* needs to
> be fixed first.
>

It is not. The argument is that this is a core primitive, used a lot
with sizes where rep stos is detrimental to its performance. There is
no urgency, but eventually someone(tm) should sort it out. For
$reasons I don't want to do it myself.

I do bring it up in the context of the init-on-alloc machinery because
it disfigures whatever results are obtained testing on x86-64 -- they
can get exactly the same effect for much smaller cost, consequently
they should have interest in sorting this out.

General point though was that the work should have sanity-checked
performance of the primitive it relies on, instead of assuming it is
~optimal. I'm guilty of this mistake myself, so not going to throw
stones.

-- 
Mateusz Guzik <mjguzik gmail.com>