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...
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