[kernel-hardening] Re: Proposal for kernel self protection features

[Kees Cook <keescook@chromium.org>]

On Fri, Nov 6, 2015 at 6:46 PM, Greg KH <gregkh@linuxfoundation.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@gmail.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).

-Kees

-- 
Kees Cook
Chrome OS Security