All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Desaulniers <ndesaulniers@google.com>
To: Kees Cook <keescook@chromium.org>
Cc: Nathan Chancellor <nathan@kernel.org>,
	Will Deacon <will@kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	"Gustavo A . R . Silva" <gustavoars@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] hardening: Default to INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_ZERO
Date: Tue, 14 Sep 2021 11:53:38 -0700	[thread overview]
Message-ID: <CAKwvOdnrO7X8h-g9Pn8RmfJhqj2zn3HJwpQ0p2EONNtFF0w-uA@mail.gmail.com> (raw)
In-Reply-To: <202109140958.11DCC6B6@keescook>

`On Tue, Sep 14, 2021 at 10:21 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Tue, Sep 14, 2021 at 08:58:12AM -0700, Nathan Chancellor wrote:
> > On 9/14/2021 3:28 AM, Will Deacon wrote:
> > > CC_HAS_AUTO_VAR_INIT_ZERO requires a supported set of compiler options
> > > distinct from those needed by CC_HAS_AUTO_VAR_INIT_PATTERN, Fix up
> > > the Kconfig dependency for INIT_STACK_ALL_ZERO to test for the former
> > > instead of the latter, as these are the options passed by the top-level
> > > Makefile.
> > >
> > > Cc: Kees Cook <keescook@chromium.org>
> > > Cc: Nathan Chancellor <nathan@kernel.org>
> > > Cc: Nick Desaulniers <ndesaulniers@google.com>
> > > Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Fixes: dcb7c0b9461c ("hardening: Clarify Kconfig text for auto-var-init")
> > > Signed-off-by: Will Deacon <will@kernel.org>
> >
> > Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> >
> > One comment below.
> >
> > > ---
> > >
> > > I just noticed this while reading the code and I suspect it doesn't really
> > > matter in practice.
> > >
> > >   security/Kconfig.hardening | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
> > > index 90cbaff86e13..341e2fdcba94 100644
> > > --- a/security/Kconfig.hardening
> > > +++ b/security/Kconfig.hardening
> > > @@ -29,7 +29,7 @@ choice
> > >     prompt "Initialize kernel stack variables at function entry"
> > >     default GCC_PLUGIN_STRUCTLEAK_BYREF_ALL if COMPILE_TEST && GCC_PLUGINS
> > >     default INIT_STACK_ALL_PATTERN if COMPILE_TEST && CC_HAS_AUTO_VAR_INIT_PATTERN
> > > -   default INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_PATTERN
> > > +   default INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_ZERO
> > >     default INIT_STACK_NONE
> > >     help
> > >       This option enables initialization of stack variables at
> > >
> >
> > While I think this change is correct in and of itself,
> > CONFIG_INIT_STACK_ALL_ZERO is broken with GCC 12.x, as
> > CONFIG_CC_HAS_AUTO_VAR_INIT_ZERO won't be set even though GCC now supports
> > -ftrivial-auto-var-init=zero because GCC does not implement the
> > -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
> > flag for obvious reasons ;) the cc-option call probably needs to be
> > adjusted.
>
> GCC silently ignores the -enable flag, so things actually work correctly
> as-is.

So then would that mean that CC_HAS_AUTO_VAR_INIT_ZERO_WITH_ENABLE
evaluates to true then, in your patch below?

Rather than create 2 new kconfigs with 1 new invocation of the
compiler via cc-option, how about just adding an `ifdef
CONFIG_CC_IS_CLANG` guard around adding the obnoxious flag to
`KBUILD_CFLAGS` in the top level Makefile?

> But, yes, it makes the command line long and doesn't make sense.
> How about we do this instead:
>
> diff --git a/Makefile b/Makefile
> index 34a0afc3a8eb..34439deac939 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -831,12 +831,11 @@ endif
>
>  # Initialize all stack variables with a zero value.
>  ifdef CONFIG_INIT_STACK_ALL_ZERO
> -# Future support for zero initialization is still being debated, see
> -# https://bugs.llvm.org/show_bug.cgi?id=45497. These flags are subject to being
> -# renamed or dropped.
>  KBUILD_CFLAGS  += -ftrivial-auto-var-init=zero
> +ifdef CONFIG_CC_HAS_AUTO_VAR_INIT_ZERO_WITH_ENABLE
>  KBUILD_CFLAGS  += -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
>  endif
> +endif
>
>  # While VLAs have been removed, GCC produces unreachable stack probes
>  # for the randomize_kstack_offset feature. Disable it for all compilers.
> diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
> index 90cbaff86e13..beea81df3081 100644
> --- a/security/Kconfig.hardening
> +++ b/security/Kconfig.hardening
> @@ -22,14 +22,22 @@ menu "Memory initialization"
>  config CC_HAS_AUTO_VAR_INIT_PATTERN
>         def_bool $(cc-option,-ftrivial-auto-var-init=pattern)
>
> +config CC_HAS_AUTO_VAR_INIT_ZERO_WITHOUT_ENABLE
> +       def_bool $(cc-option,-ftrivial-auto-var-init=zero)
> +
> +config CC_HAS_AUTO_VAR_INIT_ZERO_WITH_ENABLE
> +       # https://bugs.llvm.org/show_bug.cgi?id=45497
> +       def_bool !CC_HAS_AUTO_VAR_INIT_ZERO_WITHOUT_ENABLE && \
> +                $(cc-option,-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang)
> +
>  config CC_HAS_AUTO_VAR_INIT_ZERO
> -       def_bool $(cc-option,-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang)
> +       def_bool CC_HAS_AUTO_VAR_INIT_ZERO_WITHOUT_ENABLE || CC_HAS_AUTO_VAR_INIT_ZERO_WITH_ENABLE
>
>  choice
>         prompt "Initialize kernel stack variables at function entry"
>         default GCC_PLUGIN_STRUCTLEAK_BYREF_ALL if COMPILE_TEST && GCC_PLUGINS
>         default INIT_STACK_ALL_PATTERN if COMPILE_TEST && CC_HAS_AUTO_VAR_INIT_PATTERN
> -       default INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_PATTERN
> +       default INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_ZERO
>         default INIT_STACK_NONE
>         help
>           This option enables initialization of stack variables at
>
>
>
> --
> Kees Cook



-- 
Thanks,
~Nick Desaulniers

  reply	other threads:[~2021-09-14 18:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-14 10:28 [PATCH] hardening: Default to INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_ZERO Will Deacon
2021-09-14 15:58 ` Nathan Chancellor
2021-09-14 17:21   ` Kees Cook
2021-09-14 18:53     ` Nick Desaulniers [this message]
2021-09-14 19:09       ` Kees Cook
2021-09-14 19:14       ` Kees Cook
2021-09-14 19:22         ` Nick Desaulniers
2021-09-14 19:36         ` Nathan Chancellor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKwvOdnrO7X8h-g9Pn8RmfJhqj2zn3HJwpQ0p2EONNtFF0w-uA@mail.gmail.com \
    --to=ndesaulniers@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavoars@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.