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]

Message-ID: <CAGudoHFf87OmvmS-wm92MyPC-3yyXMUw=-BTzSNmVLXrk55U5A@mail.gmail.com>
Date:   Sat, 4 Mar 2023 21:42:21 +0100
From:   Mateusz Guzik <mjguzik@...il.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Alexander Potapenko <glider@...gle.com>,
        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/4/23, Al Viro <viro@...iv.linux.org.uk> wrote:
> On Fri, Mar 03, 2023 at 09:39:11PM +0100, Mateusz Guzik wrote:
>
>> the allocation routine does not have any information about the size
>> available at compilation time, so has to resort to a memset call at
>> runtime. Instead, should this be:
>>
>> f = kmem_cache_alloc(...);
>> memset(f, 0, sizeof(*f));
>>
>> ... the compiler could in principle inititalize stuff as indicated by
>> code and emit zerofill for the rest. Interestingly, last I checked
>> neither clang nor gcc knew how to do it, they instead resort to a full
>> sized memset anyway, which is quite a bummer.
>
> For struct file I wouldn't expect a win from that, TBH.
>

That was mostly for illustrative purposes, but you are right -- turns
out the slab is 256 bytes in size per obj and only a small fraction of
it is inititalized in the allocation routine. Good candidate to always
punt to memset in the allocator as it happens now.

Bummer though, it is also one of the 2 most memset'ed during kernel
build. The other one allocated at the same rate is lsm_file_cache and
that's only 32 bytes in size, so it will get a win.

-- 
Mateusz Guzik <mjguzik gmail.com>