On 10/16/10 08:54 AM, Richard L. Hamilton wrote:
Doesn't help with existing binaries, but it's good to know for
when one can re-link. If there's a way to construct an
LD_PRELOAD'able shared object to do the trick for existing
binaries, I don't see how given the description of mprotect(2),
to specify the entire present (and future) stack or heap of a process.
From some of the stuff I've looked at, it seems that executables were
first widely built to disable an executable stack
(using something as boring as /usr/bin/who as the test case)
in Solaris 9; on Solaris 8, I didn't see a program header for the stack for
the "who" executable, but when I recompiled with the -M option you
gave, and checked the new binary with elfdump, I saw the additional
program header.
There are a few oddball programs that legitimately want a segment
that's both writable and executable (because they compile on-the-fly);
some LISP interpreters used to do that, I think; and I can imagine that
some Forth implementations might want to do strange things. (I wonder
if the JVM does anything like that?) But I suppose they ought
to create an explicit anonymous mapping with the permissions they
desire for that use.
I believe you've already covered the essential facts, so allow me to toss
out some related supplemental trivia...
The stack permissions are set up within exec, based on the executable's
PT_SUNWSTACK program header, 'set noexec_user_stack' in /etc/system,
and failing those, the ABI mandated default.
The stack headers that come in later with other objects don't have a
vote in this, and their PT_SUNWSTACK headers are ignored, including
PRELOAD objects.
Another point of trivia is that if you have an executable with a
PT_SUNWSTACK, you can use elfedit to make its stack executable:
% elfedit -e 'phdr:p_flags -or sunwstack x' /bin/ls my.ls
% elfdump -p my.ls
Program Header[6]:
p_vaddr: 0 p_flags: [ PF_X PF_W PF_R ]
p_paddr: 0 p_type: [ PT_SUNWSTACK ]
p_filesz: 0 p_memsz: 0
p_offset: 0 p_align: 0
Unfortunately, the reverse is generally not possible: ld doesn't issue a
PT_SUNWSTACK when the permissions match the ABI defaults, so there's
nothing there for you to edit.
When I introduced the new mapfile syntax for ld earlier this year,
the question of whether we could change the default to make stacks
non-executable came up. I asked around, and the general consensus
seemed to be that while no one wants an executable stack, that going
against the ABI seemed to be a step too far.
All of which seems to say that linking with
-M /usr/lib/ld/map.noexstk
is about the best you can currently do.
- Ali
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
