Hi,
On Thu, May 27, 2010 at 11:43:47AM -0700, Roland McGrath wrote:
> Yes, sorry, I'm trying to make a collection of stuff to get
ready for
> upstream. I will switch to topic branches, good idea:
>
http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=shortlog;h=refs/heads...
Not that I need to micromanage your branches for you, but that appears to
be just a cutoff of the same "everything" branch, not a separate topic
branch. A topic branch has only the commits about this topic relative to
the baseline, and the baseline should be some upstream tree state. i.e.,
"git log origin/master...kees/nx-emu" would show only these three patches.
Hmm, that was my intention. I am new to using topic branches, so I'm
probably screwing something up here. AFAICT, I do only have the 3 nx-emu
patches on top of current linux-2.6's master. What do you see when you try
that git log? (Note that I just rebased again against linux-2.6 today.)
> The "x86: brk away from exec rand area" patch
represents a fix to a real
> problem, though, so at the very least, please review that one. It's a
> corner case only for PIE, but it does happen. There might be a more
> elegant solution, but my patch seems to do the job.
Ok. I think this should be reviewed in the normal upstream way, with x86
maintainers CC'd, not just by us.
Sorry I wasn't clear about this one; it's a fix for a problem introduced
by the exec-shield ASLR. Mainline does not suffer from this problem, which
is why I was hoping other folks here would want to look at it.
Well, mostly I wanted to collapse Ubuntu's 3 nx-emu patches into a single
patch, which is the same as what Fedora uses so we can all be on the same
page, hence the git branch, etc.
Right. I think all that stuff becomes much less confusing if we
integrate
the separate pieces one at a time.
I will add parameterizing the upstream ASLR to my TODO list, but I don't
think it'll get prioritized up to the top for a while. If anyone else
pokes at this, please let me know and we can compare notes.
> Other objections are that it isn't "perfect" (i.e.
the bss areas of loaded
> libraries end up being executable). I personally don't mind this -- it's
> better than nothing on hardware lacking the NX bit.
Agreed. It's also worthwhile to note that even on current hardware,
you don't get NX in 32-bit kernels unless you use CONFIG_X86_PAE.
Right, exactly. This was the reason I worked with HPA to clarify the
boot-time NX messages in upstream x86[1]. I wanted people to be able to see
their actual state of NX protection.
-Kees
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit...
--
Kees Cook
Ubuntu Security Team