[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jKhZWMfKWvj2QhU8LaXD4CqO9oVZ==Ux919jN7fKG8okg@mail.gmail.com>
Date: Wed, 16 May 2018 23:26:20 -0700
From: Kees Cook <keescook@...omium.org>
To: Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc: linux-kbuild <linux-kbuild@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Sam Ravnborg <sam@...nborg.org>,
Ulf Magnusson <ulfalizer@...il.com>,
"Luis R . Rodriguez" <mcgrof@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Nicholas Piggin <npiggin@...il.com>,
Emese Revfy <re.emese@...il.com>, X86 ML <x86@...nel.org>
Subject: Re: [PATCH v4 23/31] stack-protector: test compiler capability in
Kconfig and drop AUTO mode
On Wed, May 16, 2018 at 11:17 PM, Masahiro Yamada
<yamada.masahiro@...ionext.com> wrote:
> Move the test for -fstack-protector(-strong) option to Kconfig.
>
> If the compiler does not support the option, the corresponding menu
> is automatically hidden. If STRONG is not supported, it will fall
> back to REGULAR. If REGULAR is not supported, it will be disabled.
> This means, AUTO is implicitly handled by the dependency solver of
> Kconfig, hence removed.
>
> I also turned the 'choice' into only two boolean symbols. The use of
> 'choice' is not a good idea here, because all of all{yes,mod,no}config
> would choose the first visible value, while we want allnoconfig to
> disable as many features as possible.
>
> X86 has additional shell scripts in case the compiler supports those
> options, but generates broken code. I added CC_HAS_SANE_STACKPROTECTOR
> to test this. I had to add -m32 to gcc-x86_32-has-stack-protector.sh
> to make it work correctly.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
Thanks!
Acked-by: Kees Cook <keescook@...omium.org>
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists