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: <CAGXu5jKSp=T+ZixQyc3f5Lhj3x5xRsq_UDE+8dB4yKL_-N+E4Q@mail.gmail.com>
Date:   Thu, 22 Jun 2017 17:18:40 -0700
From:   Kees Cook <keescook@...gle.com>
To:     linux-kbuild <linux-kbuild@...r.kernel.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux-Next <linux-next@...r.kernel.org>
Subject: Re: enabling COMPILE_TEST support for GCC plugins in v4.11

*thread necromancy*

On Fri, Dec 9, 2016 at 11:40 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Fri, Dec 9, 2016 at 11:12 AM, Kees Cook <keescook@...gle.com> wrote:
>> I'm starting to wonder if we need to expose the compiler version to
>> Kconfig so that "all*config" builds for earlier compiler will
>> automatically leave things like plugins off. But I have no idea what
>> the right approach for that might be.
>
> We had some broken mock-up of a config option that did a "system()"
> call to do some shell scripting for filling in config options (ie turn
> a fail/pass into false/true boolean automatically with something like
>
>    config COMPILER_SUPPORTS_XYZ
>        bool
>        option shell="gcc -XYZ"
>
> The idea is really solid: move a lot of the nasty ad-hoc runtime
> testing in the Makefiles to the configuration stage. I would seriously
> like to see this, so that we could replace the stupid
>
>   CFLAGS_KCOV     := $(call cc-option,-fsanitize-coverage=trace-pc,)
>
> with just nicer thing (ok, that's a bad example, but some of the other
> cc-option cases are really pretty fundamental to kernel configuration,
> and it really matters whether the compiler supports something or not).
>
> The main problem was actually that we don't have good infrastructure
> for passing in the compiler environment etc to kbuild.
>
> I forgot who did that mock-up (and what the exact syntax was), but it
> was pretty simple.

Yeah, agreed; I would love this for much more than just gcc plugins.
I'd rather that compiler-specific things were Kconfig-sane with
discoverable reasons for a Kconfig being unavailable.

Does anyone on the kbuild list remember where this mock-up was? I
haven't been able to find anything from searches (besides this thread
itself), and getting some ideas on how to approach it would be nice.
The way the .config file gets magically reloaded seems like solving
this could be very weird.

Thanks,

-Kees

-- 
Kees Cook
Pixel Security

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ