On 10/17/10 4:58 AM, Richard L. Hamilton wrote:
While it doesn't help existing binaries, would it be possible
to for new 32-bit binaries persuade the linker to issue a
redundant (same as ABI) PT_SUNWSTACK header? That I
suppose elfedit _would_ be able to change after-the-fact.
I gather one could do it indirectly, by linking with -M /usr/lib/ld/map.noexstk
and then restoring stack execute permission with elfedit
(so that someone could take it away again later if they wanted to),
but that's clearly silly.
[Update]
I just tried back on SXCE snv_97 (still haven't updated) with a map file
containing
stack = STACK ?RWX;
and that appeared to work - the header was generated with the requested
permissions. So it ought to be rather easy to change the linker to just
generate the header explicitly by default.
The point would be if inserting the seemingly redundant header could
happen by default, which would allow someone to correct the developer's
omission of turning off stack execute permission when linking.
OTOH, I suppose elfedit would mess with signed executables (not that
they're that big a deal until enforcement is generally available).
And of course, whenever reasonably expected calculations involving
future times would pass the Jan 19 03:14:07 2038 mark, the existing
32-bit ABI would be broken anyway. (to figure out something
involving a 30 year mortgage, that would already have been a problem
for a couple of years now...) Too bad larger time_t wasn't part of largefile
support.
I've had the same thought about having ld always generate
a PT_SUNWSTACK, and even sent some internal email yesterday
proposing it to my fellow linker alien. It's actually simpler
than what we do now, since we'd just remove the code that
checks the header flags against the ABI defaults before issuing
the header. It seems reasonable to me, and we'll see what others think.
I don't view the fact that elfedit breaks the signature of an
object as a problem. If we deliver an object with an executable
stack, and it's modified in the field, that's the sort of thing
you'd want to detect.
You can certainly cause ld to inject a redundant header yourself,
using a mapfile. However, as you pointed out earlier in this thread,
it's a rare application that really needs an executable stack. So
if you're aware enough of the issue to be able to arrange for a
PT_SUNWSTACK to be added to the object with a mapfile, you might as well
and make it non-executable, rather than the redundant one. The redundant
header is only really helpful if it's always put there by ld as a default
action.
- Ali
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
