After the thundering disinterest when I asked, I've nixed the exec-shield=2 code from rawhide's execshield patch. That leaves no meaning for the exec-shield boot/sysctl parameter except that, on x86-32 kernels only, exec-shield=0 disables segmentation hacks when NX is not available (i.e. non-PAE or ancient hardware). So I've removed it from sysctl except for x86-32. I also removed some random lingering cruft that AFAICT really didn't do anything useful any more. We've whittled execshield.patch down to where all the really crufty parts relate only to the x86-32 segmentation hack for old hardware/non-PAE. There is only one piece of code actually active on other machines/configs, and even that is used only for 32-bit x86 processes. I hope to manage to cajole Ingo into either upstreaming or punting that one thing, the different arch_get_unmapped_area algorithm used for PROT_EXEC mappings. I can't tell if it's actually of any use when we're not using the segmentation hack or not. If it is, some version of it belongs upstream. Thanks, Roland

Ok. So these are really two independent things. Let's address each one separately. I've split them into two separate patches for rawhide. The rawhide kernel builds with either, both, or neither of these, so they are really separable. You can find them at: http://cvs.fedoraproject.org/viewvc/devel/kernel/ linux-2.6-32bit-mmap-exec-randomization.patch linux-2.6-i386-nx-emulation.patch 32bit-mmap-exec-randomization.patch is now pretty small: arch/x86/mm/mmap.c | 3 + arch/x86/vdso/vdso32-setup.c | 2 b/include/linux/sched.h | 4 + b/mm/mmap.c | 91 ++++++++++++++++++++++++++++++++++++++++--- include/linux/mm.h | 8 +++ include/linux/mm_types.h | 3 + mm/mremap.c | 4 - 7 files changed, 106 insertions(+), 9 deletions(-) We'd sure be happy if you wanted to clean that up and maintain it on some tip branch, whether or not it ever gets merged. wrt clean-up, IMHO it would be cleanest to just add the prot argument to get_unmapped_area and all its cousins (fs hooks, etc). That alone doesn't seem like it should be especially controversial upstream. It now has almost every mmap argument, and this would add the missing one. It seems quite reasonable that arch or driver hooks might want to use PROT_* bits as part of the decision. desireable for all 32-bit processes, not just on x86. But the patch we have now only touches x86 as it is, and it seems unlikely anyone really cares about maximal exploit mitigation for other machines to bother with. I would have thought you could have just put it in the x86 arch function upstream. Last I knew, you had some pull with the x86 arch maintainers. ;-) Now, as to i386-nx-emulation.patch, a separate subject. Again, we would not mind one bit if you wanted to clean it up and maintain it on some tip tree. With or without that, it could use a little more cleanup (it still has the exec-shield boot/sysctl parameter that should be replaced with something more sensibly-named and cleanly implemented for just suppressing the segmentation hack). Off hand, I can't say I'm likely to bother with it. (I could be more easily convinced to put any time into it if it were ever going to be merged upstream.) Perhaps someone like Kees will want to bother, to make it a cleaner version we'd share across Ubuntu and Fedora. I figure that eventually some Fedora release cycle will stop supporting non-PAE hardware anyway and/or officially just not care about maximal exploit mitigation for non-PAE or ancient hardware. So one day we'll just drop that patch. Thanks, Roland

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

Ingo says the important point of the PROT_EXEC handling is to choose a 32-bit address that has some whole byte of 0. At the moment Linus's HEAD is v2.6.35-rc5, so no, it's not. It's on v2.6.35-rc3-262-g984bc96, which was Linus's HEAD two weeks ago. It's some git mystery I also don't follow why the ... log syntax doesn't look clean. But upstream..kees/nx-emu does look clean. So go figure. Ra ra git. Anyway, if you're trying to keep it a simple history, a fresh 'git rebase' should do it. Ingo's plan is intended to be "better" because having a 0 byte in the address is inherently helpful for defanging exploits in a qualitative sense different from simple measurement of how much randomness there is in the address selection. It is not related to NX emulation. When NX emulation is actually taking place, it's furthermore desireable to put all PROT_EXEC mappings at addresses lower than all non-PROT_EXEC mappings. So that (i.e. !(__supported_pte_mask & _PAGE_NX) tests) could perhaps influence what randomization details you want to use. But that is really the secondary concern for us. Frankly, I'm more interested in you and Ingo agreeing on new randomization behavior for executable mappings and seeing if we can't get that (or at least configurability that makes it an option) in upstream. But since you asked and it was easy: git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-roland.git Two branches: fedora/x86-nx-emulation Ingo thinks this will never go upstream. That being the case, it's more or less fine as it stands. The only cleanup it really needs is to replace the exec-shield sysctl/boot parameter with something more sensically named. The only function of it is to suppress the NX emulation on a machine that would otherwise do it (i.e. has no NX). Changing the sysctl only affects new processes, since it just causes "arch_add_exec_range(current->mm, -1);". But disabling this at boot time means it can leave sysenter enabled, which exec-shield=0 now does. Once you've done that, you can't really usefully enable the sysctl later, since you'll still be using sysenter, which breaks the segmentation every time. So perhaps you should not be able to reenable it by sysctl at all. I don't really know why anyone might want to disable it, except for bugs in it. So it probably doesn't matter much what knobs we leave here. But the current one is stupid. fedora/32bit-mmap-exec-randomization This can probably do with being rewritten from scratch, in fact. I said before that I think the clean change, and the approach that I'd prefer if I were upstream, is to just adjust the get_unmapped_area function and hooks throughout to take the prot argument, rather than adding the second hook. Whatever the cleaned-up version of executable mapping logic is, it really belongs in a generic version of the function, it's desireable for any 32-bit process. We should do a little jiggery so that sys_x86_64.c's function can call that generic code instead of duplicating it wholesale by cut&paste as it is now. If you and Ingo can agree on what the actual address selection algorithm should be for 32-bit PROT_EXEC mappings, I can be talked into doing all the glue and cleanup juggling around it. Thanks, Roland