upstream exec-shield git tree

[Roland McGrath]

Let's address the two branches separately, since they have different issues
and are only slightly related at this point.

I'm well past ready to be done thinking about this stuff.  If you and Dave
agree on the details, then I'm happy to be out of the loop in the future.

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

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

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

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

IMHO it should be upstreamed, with whatever reworking is required for that.
But Ingo has never really responded usefully about that.  I don't see any
rationale for this to be carried forever in distros without getting
resolved upstream.  I'd be willing to help with the reworking if there is
some real engagement upstream about getting it resolved.  But I have no
interest in arguing for or about it.

The brk fix takes this farther in the direction of kludginess that seems
unlikely to fit how a clean reworking for upstream would be done.  Given
the kludgey nature of the whole branch, it's not drastically worse, and is
a fix for a real problem.  I don't understand why your fix should only
apply to 32-bit kernels, since the rest of the branch treats 32-bit
processes the same on both 64-bit and 32-bit kernels.

My first choice would be that you and Ingo work this out in a way that
upstream can accept.

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.


Thanks,
Roland