Date: Sun, 8 Nov 2015 12:28:07 +0100 From: Emese Revfy <re.emese@...il.com> To: Josh Triplett <josh@...htriplett.org> 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 Sun, 8 Nov 2015 00:21:55 -0800 Josh Triplett <josh@...htriplett.org> 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. -- Emese
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.