[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKv+Gu9x8LL+7hhdgux4EP1kXAWz_kodiZ208EBz7P=TvGpn8w@mail.gmail.com>
Date: Sat, 7 Nov 2015 13:41:07 +0100
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
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>
Subject: Re: Re: Proposal for kernel self protection features
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)
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.
