Date: Fri, 6 Nov 2015 21:42:17 -0800 From: Josh Triplett <josh@...htriplett.org> To: Kees Cook <keescook@...omium.org> Cc: Greg KH <gregkh@...uxfoundation.org>, Emese Revfy <re.emese@...il.com>, "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 Fri, Nov 06, 2015 at 08:16:59PM -0800, Kees Cook wrote: > On Fri, Nov 6, 2015 at 6:46 PM, Greg KH <gregkh@...uxfoundation.org> wrote: > > On Fri, Nov 06, 2015 at 04:25:08PM -0800, Josh Triplett wrote: > >> On Fri, Nov 06, 2015 at 03:30:39PM -0800, Kees Cook wrote: > >> > On Fri, Nov 6, 2015 at 2:55 PM, Emese Revfy <re.emese@...il.com> wrote: > >> > > * initify: This plugin isn't security related either. > >> > > It moves string constants (__func__ and function string arguments > >> > > marked by the nocapture attribute) only referenced in > >> > > __init/__exit functions to __initconst/__exitconst sections. > >> > > It reduces memory usage (many kB), I think it may be important for > >> > > embedded systems. > >> > > >> > I bet the Tinification project ( https://tiny.wiki.kernel.org/ ) would > >> > be interested in this! (CCing Josh for thoughts.) > >> > >> I'd be quite interested. > >> > >> Could the plugin operate in a mode where it emits warnings to add such > >> annotations explicitly in the code, rather than just automatically > >> moving the data? > > > > That would be nice for the constanfy mode as well, especially as some > > people aren't using gcc to build the kernel anymore, so it would be good > > to mark these "for real" in the .c code wherever possible to allow other > > compilers to take advantage of the plugin indirectly. > > Yeah, I think both modes have value, but I want to make sure we keep > in mind that gaining these plugins in like using the stack-protector > flag in gcc: the build results will cover non-upstream code too. I > want to be sure that our many many downstream users of the kernel will > still gain the benefits (i.e. it's less useful to Linux everywhere in > the world if only the upstream code has been fixed). 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. (For that matter, as the LLVM Linux project progresses, it might actually prove easier to provide a clang-based plugin.) - Josh Triplett
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.