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=cbdd1aea...
http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=commitdiff;h=232036cd...
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=70bd5...
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%20H...
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