Yeah, Ubuntu is in a similar situation, but I fear it's still
Yeah, well, I said "some Fedora cycle" and it may be 2*several of those too.
We aren't really the people who decide when to narrow the target set of CPUs.
It seems like the patches you've got still don't have the brk
fix I sent a while back? (Looks like the va_randomize fix was done,
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.
Also, it looks like the ASLR is seriously flawed. In actual testing,
ASLR in this patch set is extremely predictable due to how it does the
reordering, which actually reduces its entropy. :( I haven't worked out a
good way to fix it yet, though, but I suspect doing a base offset like is
done in mainline is the way to go, though the range is so tiny, I'm not
sure how to best deal with it. Maybe wrap around in the SHLIB_BASE through
0x08000000 range? Anyway, running "ldd $(which mysql)" 1000 times
sometimes shows libc in the same place almost 500 of those times.
I've never thought much about the details of the randomization algorithms
and I don't much intend to. Ingo hatched all that and I'd be happy to see
the two of you hash out something that makes more sense.
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.)
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.)
Regardless, having a branch rebased on upstream linux would be nice.
got one here at the moment:
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`
git log v2.6.35-rc3-262-g984bc96..kees/nx-emu
shows just the three patches.
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
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,
but I'd like it better if you started from our current two patches instead.