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/nx-emu > > 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=commitdiff;h=4b0f3b81eb33ef18283aa71440cccfede1753ae0 -- Kees Cook Ubuntu Security Team _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
