> Yeah, Ubuntu is in a similar situation, but I fear it's still several years > out. 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 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. > Also, it looks like the ASLR is seriously flawed. In actual testing, the > 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. 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. > 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, but I'd like it better if you started from our current two patches instead. ;-) Thanks, Roland _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
