[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+rthh_2bc86wL0ke5J7MAzsuC+Ly73MvW+cCXK0BmzTY_N+Rw@mail.gmail.com>
Date: Sun, 8 Nov 2015 11:09:34 +0100
From: Mathias Krause <minipli@...glemail.com>
To: kernel-hardening@...ts.openwall.com
Cc: Kees Cook <keescook@...omium.org>, Emese Revfy <re.emese@...il.com>,
PaX Team <pageexec@...email.hu>, Brad Spengler <spender@...ecurity.net>,
Greg KH <gregkh@...uxfoundation.org>, Theodore Tso <tytso@...gle.com>,
Josh Triplett <josh@...htriplett.org>
Subject: Re: Re: Proposal for kernel self protection features
On 7 November 2015 at 13:41, Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:
> On 7 November 2015 at 01:25, Josh Triplett <josh@...htriplett.org> 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?
>>
>
> Well, I suppose this operates primarily on string literals and
> initializers, for which there really isn't a way to annotate them
> other than doing something like
>
> #define INITSTR(x) ({ static char const __initconst __str[] = #x; __str; })
>
> which unfortunately breaks the concatenation of string literals (e.g.,
> 'printk(KERN_ERR INITSTR(foo))' will not work)
There were multiple attempts in the past to do this kind of annotation
on a source code level. The last one being [1], attempting to provide
pr_<LVL>() style of helpers for this. But it was shot down by Ingo
[2].
So I don't think a mode were the plugin generates patches is of much
use as those won't be accepted anyway. It's nice to get a feeling for
the coverage, but not so much for actual code changes.
Regards,
Mathias
[1] https://lkml.org/lkml/2014/8/21/255
[2] https://lkml.org/lkml/2014/8/21/290
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.
