upstream exec-shield git tree

[Kees Cook]

Hi,

On Mon, Nov 08, 2010 at 11:46:16AM -0800, Roland McGrath wrote:
> * x86-nx-emulation
> 
> I merged your trivia patch, and then rebased the branch on v2.6.36, since
> that's what rawhide currently starts from.  We seem to think this one will

Kernel.org's view of the tree hasn't updated yet, but I had two patches for
x86-nx-emulation:

http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=commitdiff;h=cbdd1aea211eb6f69592b4ed0adf3cd46082d016
http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=commitdiff;h=232036cd668cdd4f91c4471a3a5d4a0e6a207101

The latter one is trivial, the former is the one that Dave extracted from
my original patch to this list.

> never have a chance of going upstream.  Its only use is for hardware that
> has been obsolete for some years now.  I imagine one day we'll drop it from
> Fedora when that hardware is no longer of concern (though that may well be
> some more years off).

Right, I think Ubuntu will be in a similar position eventually. My take on
it is that once 64-bit is considered the default image to be used for new
installs, we'll likely drop the nx-emu patch from the kernel.

> If there is to be a canonical git branch for this in the future, I'm happy
> to have it be the one you maintain.  I'll let Dave and Kyle decide how to
> deal with that for Fedora.  (Using a single rpm patch that is the whole
> branch diff makes sense to me.)

I'm happy to take this on if we're all actually sending commits there.

> * 32bit-mmap-exec-randomization
> 
> Your patch's comment says "in the case of NX emulation", but this has
> nothing directly to do with that.  So that comment is just confusing in
> an area that's already too complex for anyone to keep track of.

Do you mean this patch?
http://kernel.ubuntu.com/git?p=kees/ubuntu-natty.git;a=commitdiff;h=70bd5bc09737f450d3cdc86a77d570d3c68980a7

> Ingo says this stuff is worthwhile for any 32-bit platform.  Lacking it
> makes NX emulation especially useless, but that doesn't mean this code is
> "for NX emulation".

So, in my opinion, the ASCII-armor ASLR is bad when compared to
the upstream ASLR. As implemented, it has close to 0 entropy, in
fact. However, a system using nx-emu has _actually_ 0 entropy for its
exec ranges, so this ASLR is an improvement, however small. As a result, I
think it fundamentally weakens the system if this ASCII-armor ASLR is used
in the general case; the existing ASLR uses considerably more entropy.

Looking at it from a non-entropy perspective (i.e. it provides addresses
that are harder to target due to the embedded null byte), this protection
is significantly less useful these days given the use of FORTIFY_SOURCE
and stack-protector. i.e. it's only really a protection when using
strcpy()-like functions to overwrite addresses, and nearly all of that
is caught earlier. Therefore, I chose to have Ubuntu only use ASCII-armor
ASLR when nx-emu is in use.

> IMHO it should be upstreamed, with whatever reworking is required for that.

I'm not really interested in it going upstream, but I would like to see
nx-emu modified to use the upstream ASLR methods instead. I think that
would happen as part of trying to get nx-emu upstreamed, but that'll be
kind of a long/ugly effort.

> My first choice would be that you and Ingo work this out in a way that
> upstream can accept.

nx-emu is lower on my list than some of the other features from
PaX/grsecurity, but I'll get to it eventually:
https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Upstream%20Hardening

> In the interim for Fedora, I'd rather see this change with a comment that
> is not misleading, and with some resolution to the question of why you
> applied the fix only on 32-bit kernels.  But I don't really care any more.
> Since Dave already took your patch as it is, whatever details you work out
> with him are OK by me.

Well, for the Fedora kernel, it looks like Dave removed my ASLR w/ nx-emu
conditional element. (See urls above.) I'm fine with keeping that patch
out of the tree if we can't agree on it, but I'd like to try to convince
you (Dave? Ingo?) otherwise so we can all have the same patchset.

Note that I've also pointed Debian at these patches in an attempt to get
them using it as well:
http://wiki.debian.org/DebianKernel/Meetings

Thanks,

-Kees

-- 
Kees Cook
Ubuntu Security Team