> > >ppgsz(1) or mpss.so.1(1) can set preferred page size > for > >existing (ppgsz) or new (both) processes. > > > >Is there anything that can similarly remove execute > permission > >from the stack of 32-bit processes, without do so on > a system-wide > >basis (i.e. without putting set noexec_user_stack=1 > in /etc/system)? > Without relinking, you mean? > > If you can relink the program, there's > > -M /usr/lib/ld/map.noexstk > > >It strikes me that something like that might be good > with high risk > >programs like browsers, that are often still 32-bit, > and usually > >have a shell wrapper anyway. > > > We use this in many consolidations: > > % pmap `pgrep firefox`|grep stack > E60FA000 8K rw--R [ stack tid=2846 ] > F727A000 8K rw--R [ stack tid=14 ] > F74F8000 16K rw--R [ stack tid=13 ] > F7AF8000 16K rw--R [ stack tid=7 ] > F83FA000 8K rw--R [ stack tid=2858 ] > FA5FA000 8K rw--R [ stack tid=5 ] > FA6FA000 8K rw--R [ stack tid=4 ] > FABFA000 8K rw--R [ stack tid=3 ] > FACFA000 8K rw--R [ stack tid=2 ] > FFB9C000 400K rw--- [ stack ] > FFBFC000 16K rw--- [ stack ] > > You can detect such programs using "elfdump"; you'll > find a Program header > similar to this: > > Program Header[5]: > p_vaddr: 0 p_flags: [ PF_W PF_R > ] <- RW, no N! > p_paddr: 0 p_type: [ > PT_SUNWSTACK ] > p_filesz: 0 p_memsz: 0 > p_offset: 0 p_align: 0 > > Casper >
Thanks for the info. 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. Now...if there only weren't still 32-bit executables that aren't large-file aware. :-) -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
