linux-kernel - Re: [PATCH] [RFC] Initialization of unused function parameters

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: <CAHk-=whaWnwB8guceg8V=bA1adv74GNaMk2FEu+YQkBKUqxVoA@mail.gmail.com>
Date:   Tue, 14 Jun 2022 09:48:35 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Alexander Potapenko <glider@...gle.com>
Cc:     Evgenii Stepanov <eugenis@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        Marco Elver <elver@...gle.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Vitaly Buka <vitalybuka@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-toolchains <linux-toolchains@...r.kernel.org>
Subject: Re: [PATCH] [RFC] Initialization of unused function parameters

On Tue, Jun 14, 2022 at 7:49 AM Alexander Potapenko <glider@...gle.com> wrote:
>
> The bigger question I want to raise here is whether we want to
> discourage passing uninitialized variables to functions in the kernel
> altogether.

I'm assuming you mean pass by reference.

Some functions are really fundamentally about initializing things, and
expect uninitialized allocations.

Obviously the traditional example of this is "memset()", and that one
can be special-cased as obvious, but we probably have a ton of wrapper
things like that.

IOW, things like just "snprintf()" etc is fundamentally passed an
uninitialized buffer, because the whole point is that it will write to
that buffer.

And no, we don't want to initialize it, since the buffer may be big
(on purpose).

Now, for *small* things (like that "pointer to inode") that aren't
some kind of array or big structure, I think it might be good to
perhaps be stricter. But even there we do have cases where we pass
things by reference because the function is explicitly designed to
initialize the value: the argument isn't really "an argument", it's a
"second return value".

But always initializing in the caller sounds stupid and
counter-productive, since the point is to initialize by calling the
helper function (think things like returning a "cookie" or similar:
initializing the cookie to NULL in the caller is just plain _wrong_.

What I think might be a good model is to be able to mark such
arguments as "must be initialized by callee".

So then the rule could be that small arguments passed by reference
have to be either initialized by the caller, or the argument must have
that "initialized by callee" attribute, and then the initialization
would be enforced in the callee instead.

But making the rule be that the caller *always* has to initialize
sounds really wrong to me.

             Linus