since it's getting to be a bit late in the game to put any kernel changes to
conditionally map stuff executable even when the mapping is supposed to be
non-executable, I have some alternate proposals.  there are only two
varieties of emulated binaries that we know to have problems so far,
so I'll talk about those individually.

 (1) linux powerpc

     here, the problem is due to a linker bug that made the ELF load section
     containing the GOT non-executable when it should have been executable.
     this bug was present in the version of binutils used in the linux
     distribution that pkgsrc installs on powerpc (Suse 7.3).  more recent
     ppc distributions (such as yellowdog 3.0) are using a fixed version of
     the binutils, so it would be helpful if pkgsrc encouraged people to use
     a more modern distribution.  (suse 7.3 is also marked as "discontinued",
     so I'd think it's probably time to move to a more recent distribution
     for all architectures.  but anyway.)

     in addition to that, it would simple to write a tool to patch the
     ELF headers and turn on the execute bit in ELF binaries that need it,
     so that the effects of the linker bug are undone.  it appears that
     only statically-linked binaries are affected by the bug, so this
     shouldn't be much of a hardship.


 (2) netbsd a.out sparc

     sparc appears to be the only architecture where the hardware supports
     non-executable mappings and netbsd ever used a.out.  in this case, the
     permissions bits that are wrong are embedded directly in an instruction
     in every dynamically-linked executable (where the data segment of ld.so
     is mapped non-exectuable even though parts of it need to be executed).
     however, I think we can come up with a heuristic for patching that
     instruction so that we can write another tool for fixing these
     executables as well.


in both of these cases, the fixed binaries would continue to run fine
anyplace they used to run, but they would work under 2.0's emulation as well.

so at this point, I'm advocating not changing the kernel to deal with
this issue at all.  that will avoid any security issue, while still allowing
use of the legacy binaries (after a one-time procedure to fix them).
of course, we would need to document all this in the 2.0 release notes.

-Chuck