exec-shield=2

[Kees Cook]

On Tue, Jul 13, 2010 at 05:07:53PM -0700, Roland McGrath wrote:
> > It seems like the patches you've got still don't have the brk collision
> > fix I sent[1] a while back?  (Looks like the va_randomize fix was done,
> > though.)
> 
> I missed that one.  I don't know if it's been reported to us as a bug.
> TBH, I had really not wanted to look into any of the details of this before
> we at least nominally cleaned it up and split it into its appropriate two
> topic patches.  I've only just done that in the last week.

I don't know if it's been reported in RH, but when I first triaged
the problem in Ubuntu, I did check Fedora and I saw it there too.
I probably should have opened a bug (sorry about that) -- I ended up
forwarding the patch instead to Dave Jones and Kyle McMartin.

> In our new split, 32bit-mmap-exec-randomization.patch contains all that
> logic.  A better/cleaner rewrite of that would be great, whatever the
> details you and Ingo think work.  (It seems like it should be doable in
> ways clean enough that upstream should take it, too.  I said some details
> about that here earlier.)  That's where the brk change belongs to, though I
> leave it to you and Ingo to decide how those two should each be and fit
> together.  (I'm happy to help with making it clean and all, but I just
> don't have any input to offer on the address selection logic itself.)

Cool; it'll probably be a few months before I have time to really start
trying new ways to deal with it.

> Ingo tells us an algorithm akin to this one is desireable for any process
> with 32-bit pointers.  So it really is entirely separate from NX emulation
> per se, and should not be conditional on CONFIG_X86_32 at all.  (When it
> gets cleaned up, it might not even want to be x86-specific.)

Well, the existing ASLR infrastructure is actually pretty good -- if we
could eke out even more entropy that'd be nice.  One of our ARM kernel guys
just recently finished up getting ASLR working there, and that'll be
getting upstreamed soon.

> > Regardless, having a branch rebased on upstream linux would be nice.  I've
> > got one here at the moment:
> > http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=shortlog;h=refs/heads/nx-emu
> 
> Not all that rebased...for some reason 
> 	git log --no-merges v2.6.35-rc5...kees/nx-emu
> shows a lot.  But
> 	$ git describe `git merge-base v2.6.35-rc5 kees/nx-emu`
> 	v2.6.35-rc3-262-g984bc96
> and
> 	git log v2.6.35-rc3-262-g984bc96..kees/nx-emu
> shows just the three patches.	

Git confuses me to no end.  Is my branch not on Linus's HEAD?

> > It looks like you've added a few more CONFIG_X86_32 checks, but not as many
> > as I've got still.  Have you got any feedback on the patches I'm carrying
> > here?
> 
> Um, they look nearly identical to how our execshield.patch was before the
> clean up and split I just did recently.  Aside from the cruft that I just
> took out that you still have, you have the brk change we don't have, but
> you also have #ifdef CONFIG_X86_32'd the randomization change, which we
> don't think is the desireable change.  Not to be too transparently lazy,

Ah, yeah, that's where I was looking -- I prefer to use the upstream ASLR
when we don't have to pin the libraries in the "below 0x08000000" range.
I.e. we only use the weaker ASLR when we're forced to use the nx-emu too.

> but I'd like it better if you started from our current two patches instead.
> ;-)

Sure, I can do that -- do you want to push a git tree with those patches,
and I can work off that and send you stuff to merge?

Thanks,

-Kees

-- 
Kees Cook
Ubuntu Security Team