[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 8 Nov 2015 00:21:55 -0800
From: Josh Triplett <josh@...htriplett.org>
To: Emese Revfy <re.emese@...il.com>
Cc: Kees Cook <keescook@...omium.org>, Greg KH <gregkh@...uxfoundation.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
PaX Team <pageexec@...email.hu>,
Brad Spengler <spender@...ecurity.net>,
Theodore Tso <tytso@...gle.com>
Subject: Re: Proposal for kernel self protection features
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?
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.
