> Even not considering the segmentation based protection, it's useful (on > 32-bit) because it compresses executable mappings into an address space > region where all 32-bit addresses have a zero byte in them. 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. >From what you've said it sounds like this PROT_EXEC behavior would be 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 _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
