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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyM1uxzvU4SH3c1VYRXBRfGuqKZ4OR-O_pMoxPs7XTFug@mail.gmail.com>
Date:   Fri, 13 Apr 2018 11:11:56 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        linux-kbuild <linux-kbuild@...r.kernel.org>,
        Sam Ravnborg <sam@...nborg.org>,
        Ulf Magnusson <ulfalizer@...il.com>,
        Nicholas Piggin <npiggin@...il.com>,
        Emese Revfy <re.emese@...il.com>, X86 ML <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 21/30] stack-protector: test compiler capability in
 Kconfig and drop AUTO mode

On Fri, Apr 13, 2018 at 9:41 AM, Kees Cook <keescook@...omium.org> wrote:
>
> How about something like this instead:

I'd rather avoid the ifdef's in the Makefile if at all possible.

I'd rather expose this as a Kconfig rule, and in the Kconfig just have
an entry something like this

    config STACKPROTECTOR_FLAGS
        string
        default "-fstack-protector-strong" if CC_STACKPROTECTOR_STRONG
        default "-fstack-protector" if CC_STACKPROTECTOR
        default "-fno-stack-protector" if CC_HAS_STACKPROTECTOR_NONE
        default ""

which is really simple and straightforward. In the presense of
multiple defaults, the first is picked, so this _automatically_ does
that whole priority ordering.

And then the Makefile can just have

        KBUILD_CFLAGS += $(CONFIG_STACKPROTECTOR_FLAGS)

which seems much simpler.

It also makes more complex conditionals easier (ie different compilers
with different flags, since clang sometimes does the same thing with
another flag name), so I'd rather see this pattern in general.

I'd also *much* rather do as much as possible at Kconfig time compared
to build time. Maybe it's just shifting the costs around, but the less
"clever" things we ask "make" to do, the better.

I find our Makefiles an odd combination of really clean and simply
(the ones that just have "obj-$(CONFIG_X) += xyz.o" are just lovely)
and completely incomprehensible (all of our infrastructure support for
the simple stuff).

I'd rather have more of the simple stuff in Makefiles, less of the
complex conditionals.

                  Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ