linux-kernel - Re: [PATCH v2] [RFC] security: allow using Clang's zero initialization for stack variables

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] [day] [month] [year] [list]

Message-ID: <202006160911.BD403B5@keescook>
Date:   Tue, 16 Jun 2020 09:18:07 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Alexander Potapenko <glider@...gle.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        James Morris <jmorris@...ei.org>,
        Maciej Żenczykowski <maze@...gle.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] [RFC] security: allow using Clang's zero
 initialization for stack variables

On Tue, Jun 16, 2020 at 02:15:52PM +0200, Alexander Potapenko wrote:
> > > +KBUILD_CFLAGS        += -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
> > > +endif
> >
> > Gotta love the name...
> 
> This is basically the reason why we've been hesitating to add it to
> the kernel from the very beginning.
> 
> > Anyway, if this is enabled, and clang changes the flag or drops it, does
> > the build suddenly break?
> 
> My original intention (see v1 of this patch) was to make
> zero-initialization a secondary option of INIT_STACK_ALL, so that
> nothing changes for the existing users.
> But I agree with Kees that these options should be made distinct, as
> people may want to use them for different purposes (think debug vs.
> release builds).

Yeah, and if the flag changes again, we can adapt. But at this point,
it's getting used downstream, so we need to land the config in the
kernel.

> We could make INIT_STACK_ALL_ZERO fall back to INIT_STACK_ALL_PATTERN
> if the compiler flag goes away - does this make sense?

I don't like this idea -- I'm very hesitant to make security options do
something different than what they document. It means the end user can't
reason about how their kernel is built when looking at their CONFIGs.

> > And does gcc have something like this as well, or does that have to come
> > in a compiler plugin?
> 
> Kees mentioned someone's plans to implement that in GCC, but I don't
> think they have done it already.

I've had some GCC folks reach about about these features, but I haven't
seen any public discussion yet.

-- 
Kees Cook