Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 8 Nov 2015 12:28:07 +0100
From: Emese Revfy <>
To: Josh Triplett <>
Cc: Kees Cook <>, Greg KH <>,
 <>, PaX Team <>,
 Brad Spengler <>, Theodore Tso <>
Subject: Re: Proposal for kernel self protection features

On Sun, 8 Nov 2015 00:21:55 -0800
Josh Triplett <> wrote:

> On Sat, Nov 07, 2015 at 11:07:02PM +0100, Emese Revfy wrote:
> > 
> > > I agree in both cases: having the plugin usable in "make it so" mode for
> > > the benefit of legacy or out-of-tree code, and having it usable in
> > > "suggest changes to the source" (or outright *edit* the source and
> > > produce a patch) mode to avoid actually mandating the plugin.  Not least
> > > of which because I'd find it surprising if the plugin ever worked across
> > > as broad a range of GCC versions as the kernel typically wants to
> > > support.
> > 
> > All gcc plugins in PaX support all plugin capable gcc versions (4.5-5). 
> The kernel supports older GCC than that, though.
> > And of course the plugin infrastructure handles gcc versions that don't
> > support plugins.
> ...huh?  How does *that* work?

If a gcc plugin kernel option is enabled then the kernel Makefile prints
this out if the gcc version can support plugins but there is a problem:
"warning, your gcc installation does not support plugins, perhaps the necessary headers are missing?"
or this if the version is too old:
"warning, your gcc version does not support plugins, you should upgrade it to gcc 4.5 at least"
The compilation goes on without plugins.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.