From: Michael Ellerman <mpe@ellerman.id.au>
To: Kees Cook <keescook@chromium.org>,
"Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Cc: Emese Revfy <re.emese@gmail.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Michal Marek <mmarek@suse.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
Linux-Next <linux-next@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: [kernel-hardening] Re: [PATCH] gcc-plugins: disable under COMPILE_TEST
Date: Tue, 14 Jun 2016 12:01:38 +1000 [thread overview]
Message-ID: <1465869698.18900.2.camel@ellerman.id.au> (raw)
In-Reply-To: <CAGXu5jLYYg8QdWy0nMLLV4e4=xz7G2U7CBQjsAd5Q5PfZd48ng@mail.gmail.com>
On Mon, 2016-06-13 at 13:11 -0700, Kees Cook wrote:
> On Mon, Jun 13, 2016 at 11:32 AM, Austin S. Hemmelgarn
> <ahferroin7@gmail.com> wrote:
> > On 2016-06-12 20:18, Emese Revfy wrote:
> > >
> > > On Sun, 12 Jun 2016 15:25:39 -0700
> > > Kees Cook <keescook@chromium.org> wrote:
> > >
> > > > I don't like this because it means if someone specifically selects
> > > > some plugins in their .config, and the headers are missing, the kernel
> > > > will successfully compile. For many plugins, this results in a kernel
> > > > that lacks the requested security features, and that I really do not
> > > > want to have happening. I'm okay leaving these disabled for compile
> > > > tests for now. We can revisit this once more distros have plugins
> > > > enabled by default.
> > >
> > > You are right. Your patch is safer.
> > >
> > Why not make it so that if COMPILE_TEST is enabled, the build warns if it
> > can't find the headers, otherwise it fails? That way, people who are doing
> > all*config builds but don't have the headers will still get some build
> > coverage, and the people who are enabling it as a security feature will
> > still get build failures.
>
> I don't see a clear way to do this, but if you can find a way to make
> that happen, please send a patch! :)
Another option is to make the top-level option negative, that way when it's
enabled by allmod/yes the plugins are turned off.
So eg. you would have:
config DISABLE_GCC_PLUGINS
bool "Disable building GCC plugins"
default y
...
This makes all the problems with allmod/yes go away, and means you always honor
the users intent - when DISABLE_GCC_PLUGINS=n you can fail the build if you
can't build the plugins.
The downside is the logic's a bit awkward, ie. to enable the plugins you have to
disable the option which disables them.
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Kees Cook <keescook@chromium.org>,
"Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Cc: Emese Revfy <re.emese@gmail.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Michal Marek <mmarek@suse.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
Linux-Next <linux-next@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH] gcc-plugins: disable under COMPILE_TEST
Date: Tue, 14 Jun 2016 12:01:38 +1000 [thread overview]
Message-ID: <1465869698.18900.2.camel@ellerman.id.au> (raw)
In-Reply-To: <CAGXu5jLYYg8QdWy0nMLLV4e4=xz7G2U7CBQjsAd5Q5PfZd48ng@mail.gmail.com>
On Mon, 2016-06-13 at 13:11 -0700, Kees Cook wrote:
> On Mon, Jun 13, 2016 at 11:32 AM, Austin S. Hemmelgarn
> <ahferroin7@gmail.com> wrote:
> > On 2016-06-12 20:18, Emese Revfy wrote:
> > >
> > > On Sun, 12 Jun 2016 15:25:39 -0700
> > > Kees Cook <keescook@chromium.org> wrote:
> > >
> > > > I don't like this because it means if someone specifically selects
> > > > some plugins in their .config, and the headers are missing, the kernel
> > > > will successfully compile. For many plugins, this results in a kernel
> > > > that lacks the requested security features, and that I really do not
> > > > want to have happening. I'm okay leaving these disabled for compile
> > > > tests for now. We can revisit this once more distros have plugins
> > > > enabled by default.
> > >
> > > You are right. Your patch is safer.
> > >
> > Why not make it so that if COMPILE_TEST is enabled, the build warns if it
> > can't find the headers, otherwise it fails? That way, people who are doing
> > all*config builds but don't have the headers will still get some build
> > coverage, and the people who are enabling it as a security feature will
> > still get build failures.
>
> I don't see a clear way to do this, but if you can find a way to make
> that happen, please send a patch! :)
Another option is to make the top-level option negative, that way when it's
enabled by allmod/yes the plugins are turned off.
So eg. you would have:
config DISABLE_GCC_PLUGINS
bool "Disable building GCC plugins"
default y
...
This makes all the problems with allmod/yes go away, and means you always honor
the users intent - when DISABLE_GCC_PLUGINS=n you can fail the build if you
can't build the plugins.
The downside is the logic's a bit awkward, ie. to enable the plugins you have to
disable the option which disables them.
cheers
next prev parent reply other threads:[~2016-06-14 2:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-11 16:12 [kernel-hardening] [PATCH] gcc-plugins: disable under COMPILE_TEST Kees Cook
2016-06-11 16:12 ` Kees Cook
2016-06-11 16:29 ` [kernel-hardening] " Paul Gortmaker
2016-06-11 16:29 ` Paul Gortmaker
2016-06-11 16:29 ` Paul Gortmaker
2016-06-12 22:12 ` [kernel-hardening] " Emese Revfy
2016-06-12 22:12 ` Emese Revfy
2016-06-12 22:12 ` Emese Revfy
2016-06-12 22:25 ` [kernel-hardening] " Kees Cook
2016-06-12 22:25 ` Kees Cook
2016-06-13 0:18 ` [kernel-hardening] " Emese Revfy
2016-06-13 0:18 ` Emese Revfy
2016-06-13 18:32 ` [kernel-hardening] " Austin S. Hemmelgarn
2016-06-13 18:32 ` Austin S. Hemmelgarn
2016-06-13 20:11 ` [kernel-hardening] " Kees Cook
2016-06-13 20:11 ` Kees Cook
2016-06-14 2:01 ` Michael Ellerman [this message]
2016-06-14 2:01 ` Michael Ellerman
2016-06-13 7:52 ` [kernel-hardening] " Sudip Mukherjee
2016-06-13 7:52 ` Sudip Mukherjee
2016-06-13 8:40 ` Sedat Dilek
2016-06-13 20:15 ` [kernel-hardening] " Kees Cook
2016-06-13 20:15 ` Kees Cook
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=1465869698.18900.2.camel@ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=ahferroin7@gmail.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=mmarek@suse.com \
--cc=paul.gortmaker@windriver.com \
--cc=re.emese@gmail.com \
--cc=sfr@canb.auug.org.au \
--cc=sudipm.mukherjee@gmail.com \
/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.