> On 10/20/10 3:39 AM, casper....@sun.com wrote: > > > > > >> I had a few minutes today to try an > experiment, and I'm afraid > >> the idea of having ld always generate a > PT_SUNWSTACK is a non-starter. > >> > >> The problem is that it overrides the behavior of > 'set noexec_user_stack=1' > >> in /etc/system, and can therefore quietly allow > programs that would > >> not previously been able to execute on the stack > do so. > >> > > > > Thanks for this investigation. > > > > There is another issue we haven't explored is the > use a system call; > > there's a sysconf(_SC_STACK_PROT) but there's no > way to set in on the > > fly. If we create a function to change it on the > fly, we could make a > > LD_PRELOAD object which enforce it. The current > mapped pages would not be > > protected but threadstacks and additional pages > would be rw-. > > > > Casper > > > > Yet another possibility would be for ld to issue an > extra PT_NULL > program header, rather than a PT_SUNWSTACK. PT_NULL > is a no-op, and > would not alter behavior, but elfedit can be later be > used to turn it > into something else, such as PT_SUNWSTACK.
While I still like the idea of a runtime function (new syscall or extension to mprotect()) to control default stack or heap permissions (mainly for use with a preloadable shared object to apply to existing binaries that don't have a spare program header, although some other runtime uses might be imaginable), leaving oneself the leeway to patch a binary statically also seems desirable. I gather that something had been done to leave some room so that for newer binaries, one could patch in runpath changes longer than the original runpath (whereas for older ones, one might well have been limited to a new runpath that fit in the same space as the old one). Are there any _current_ uses you can see for a spare unused (PT_NULL) program header other than changing it into a PT_SUNWSTACK header? (I imagine that there's always a good chance that future uses as yet unsupported might turn up, i.e. some future feature that could be retrofitted into existing binaries given a spare header to put it into; but I'm thinking now in terms of current possibilities.) -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
