Re: [PATCH] hardening: Remove Clang's enable flag for -ftrivial-auto-var-init=zero

[Kees Cook <keescook@chromium.org>]

On Mon, Oct 03, 2022 at 09:41:19AM -0700, Nathan Chancellor wrote:
> On Thu, Sep 29, 2022 at 11:06:24PM -0700, Kees Cook wrote:
> > Now that Clang's -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
> > option is no longer required, remove it from the command line. Clang 16
> > and later will warn when it is used, which will cause Kconfig to think
> > it can't use -ftrivial-auto-var-init=zero at all. Check for whether it
> > is required and only use it when so.
> > 
> > Cc: Nathan Chancellor <nathan@kernel.org>
> > Cc: Masahiro Yamada <masahiroy@kernel.org>
> > Cc: Nick Desaulniers <ndesaulniers@google.com>
> > Cc: linux-kbuild@vger.kernel.org
> > Cc: llvm@lists.linux.dev
> > Cc: stable@vger.kernel.org
> > Fixes: f02003c860d9 ("hardening: Avoid harmless Clang option under CONFIG_INIT_STACK_ALL_ZERO")
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> 
> Thanks for sending this change!
> 
> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> Tested-by: Nathan Chancellor <nathan@kernel.org>

Thanks!

> 
> Please consider getting this to Linus ASAP so that this can start
> filtering into stable now that the LLVM change has landed, as I lost the
> ability to use CONFIG_INIT_STACK_ALL_ZERO after upgrading my toolchain
> over the weekend :)

Yup -- it's in my PR for the hardening tree sent on Saturday.

> Additionally, I am not sure the fixes tag is going to ensure that this
> change automatically makes it back to 5.15 and 5.10, which have
> commit f0fe00d4972a ("security: allow using Clang's zero initialization
> for stack variables") but not commit f02003c860d9 ("hardening: Avoid
> harmless Clang option under CONFIG_INIT_STACK_ALL_ZERO"). I guess if I
> am reading the stable documentation right, we could do something like:
> 
> Cc: stable@vger.kernel.org # dcb7c0b9461c + f02003c860d9
> Fixes: f0fe00d4972a ("security: allow using Clang's zero initialization for stack variables")
> 
> but I am not sure. I guess we can always just send manual backports
> once it is merged.

Ah, good point. Yeah, probably just do backports of f02003c860d9 and
this one.

-- 
Kees Cook