exec-shield=2

[Roland McGrath]

> 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