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

[Kees Cook <keescook@chromium.org>]

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