Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Nov 2015 22:34:37 +0100
From: Emese Revfy <>
To: Kees Cook <>
Cc: ""
 <>, PaX Team <>,
 Brad Spengler <>, Greg KH
 <>, Theodore Tso <>, Josh
 Triplett <>
Subject: Re: Proposal for kernel self protection features

> >     * size_overflow_hash_aux: For out-of-tree modules.
> By out-of-tree, you mean built-out-of-tree? I assume a future

I mean out-of-tree modules e.g., zfs. But the gcc infrastructure
in PaX also supports built-out-of-tree and cross compilation.

> downstream kernel that used size_overflow would have their
> non-upstream code covered during the size_overflow_hash regeneration?
> (Though they'd be on the their own for handling the false positives.)

Yes, everybody can regenerate the hash table (the plugin prints out a message
about missing entries that I parse with a python script). I store functions
from out-of-tree modules in a separate hash table because we don't regenerate it
for every kernel version. 

> >        * gcc intentional overflow: gcc computes some expressions by overflow
> >           when it optimizes. Sadly it is doing this in the front end where
> >           there is no plugin support. Most of these false positives I handle
> >           from the plugin or sometimes I patch the kernel source code.
> >           There are some unsolved issues.
> Has there been any discussion with gcc folks about this problem?

I never tried it. PaXTeam has some open tickets
(e.g., for a long time so
because of it I haven't any courage.

> >  * structleak: This plugin forcibly initializes certain local variables
> >     based on the __user attribute that could otherwise leak kernel stack
> >     to userland if they aren't properly initialized by later code.
> >     It has small performance loss.
> Does this operate only on kernel stack structures?

Yes, it does but the coverage can be increased.

> > I think the first plugin can be a simpler plugin e.g., constify or latent_entropy.
> > Please let me know if you want one, more or all of them.
> Well I would love to see all of them upstream. :) As for first steps,
> you've convinced me about the complexity of the size_overflow plugin.
> Perhaps the constify plugin would be a good first target? Can you

Yes, I agree.

> speak to any known bugs it stopped? Having some mention of the threat
> it mitigates would be helpful. (Do I remember correctly that it
> constified security_operations, which was a common target in
> exploits?)

I don't remember any bugs, but I think spender has some exploits that
are stopped by constification :) The constify plugin stops exploits that
want to modify ops structures to control indirect calls through them.


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.