NX emulation

[Roland McGrath]

> 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.

> 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