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.
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.
Well, to use the mainline ASLR, it would have to grow a little more
knowledge about memory ranges to distinguish where the CS line was.
The NX-emulation is "just" the CS-limit bits. (I've been trying to avoid
saying "exec-shield" since AFAIU, exec-shield as a project covered much
more than just NX-emu and ASLR.) But yeah, a good first step would be to
port the NX-emu to using mainline ASLR.
Right. I think all that stuff becomes much less confusing if we integrate
the separate pieces one at a time.
Sounds like we all agree on this. :) Currently it sounds like 3
knobs:
I actually don't care about the details of the knobs at all. I just think
that one knob called "exec-shield" is indefensibly random and unhelpful.
You need to work this out with Ingo and the other x86 maintainers. Other
Fedora kernel folks might have some input based on concrete concerns from
the past. Personally, I've never had a use for any of these knobs.
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.
Thanks,
Roland