Re: [kernel-hardening] Introduction

[Daniel Micay <danielmicay@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3011 bytes --]

On Fri, 2017-01-13 at 11:06 -0800, Kees Cook wrote:
> On Fri, Jan 13, 2017 at 10:51 AM, PaX Team <pageexec@freemail.hu>
> wrote:
> > On 13 Jan 2017 at 9:54, Kees Cook wrote:
> > 
> > > PaX Team, the heuristic for STRUCTLEAK appears to be "does the
> > > struct
> > > contain anything marked __user". Is this actually a meaningful
> > > information exposure case? It seems like there are a lot more
> > > cases
> > > for exposures where there is nothing marked __user. Is that the
> > > meaning of "much smaller coverage" compared to STACKLEAK in the
> > > Kconfig?
> > 
> > STRUCTLEAK was written in response to a particular bug a few years
> > ago
> > where we didn't want to give the bug away but still wanted to fix it
> > during the embargo. the struct in question could be matched by this
> > heuristics, matching everything else (however little of it) is
> > really
> > just a free side effect. could coverage be improved? of course but
> > that
> > would take a whole lot more work (manual markups and/or data flow
> > analysis
> > in LTO mode).
> 
> Out of curiosity, do you remember which bug? I'd be curious to compare
> it against others. It seems like adding structleak to upstream still
> has value, even if the coverage isn't as complete as stackleak.

There's the performance-oblivious approach of zeroing all locals early
in the compiler pipeline and relying on compiler optimizations to remove
it when it's not required. They're already pretty good at doing it.
There can be a scale of aggressiveness for a feature like this, with
very conservative heuristics on one end (like analysis to propagate from
copy_to_user) and no heuristics at all for the other. It would be
interesting to measure that to figure out the worst case performance
scenario, particularly if it's possible to narrow down areas where it
hurts and then work out some simple heuristics to reduce the cost. Maybe
most of the cost can be alleviated by not doing arrays or by having a
size limit, etc. Maybe there are only a few areas where it really hurts
and they could be marked. Need to test before conclusions about
heuristics can be drawn.

I'm doing it for Android's userspace via Clang. It's usually very cheap
and actually costs less than SSP for most code. The top of the stack is
inherently hot data and since it's not adding branches, the main cost is
probably code size. There are some cases where it can really hurt due to
arrays on the stack, but the kernel doesn't have as many of those
particularly with large arrays. I haven't implemented it for GCC so I
haven't had a chance to try it with the kernel yet. I expect it to be
more than cheap enough for my needs though.

If nothing else, it could be a useful way to uncover bugs via the option
of a non-zero byte value for debug builds rather than the production
oriented zeroing. AFAIK, the kernel doesn't have anything to do that on
the stack, and I haven't had much luck with MSan in userspace anyway.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 866 bytes --]