Re: fix to noexec_user_stack on solaris 2.{6,7}

["Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>]

This will break calling of functions that return a structure or union.

As per sparc calling conventions the call must looks like this:

        call fun,0
        nop
        unimp <size of returned struct>

Setting CALL_DUMMY_LOCATION to AT_ENTRY_POINT doesn't handle this case.

When I was looking at the problem a long time ago, I had no idea how to
solve it properly.

> [Initial apologies if this has been dealt with.  I wasn't able
> to find a FAQ, and a searches for "noexec" and "user stack" turned 
> up nothing]
> 
> Hi,
> 
> I recently started running my solaris 2.6 boxes with the
> noexec_user_stack option that prevents anyone from executing code
> off of the data segment of a process.  This is a great security
> feature, and has been relatively painless.  I ran into a problem
> with the gdb feature "call" and "print proc()", but seem to
> have gotten around it by putting:
> 
> #define CALL_DUMMY_LOCATION          AT_ENTRY_POINT
> #define CALL_DUMMY_ADDRESS()         entry_point_address ()
> 
> at the end of gdb-4.18/gdb/config/sparc/tm-sun4sol2.h
> 
> So my questions are:
> 	- has someone already fixed this, and I have a shiny new wheel?
> 	- is this a proper fix?  I have read only enough of the gdb code
> 			to get this working...
> 	- does this break anything else my limited tests
> 		haven't found?
> 	- would it be possible/advisable to get a ./configure
> 		option of "--non-executable-data-stack" to
> 		enable this?  I know linux has a similar patch
> 		to turn of the user stack, so this is useful
> 		for other architectures.
> 
> Assuming I am on the right track, I can submit a patch.  I
> just wanted to get some sanity checks first :)~
> 
> TIA, and for what its worth, gdb is a great program, so thanks!
> 
> 
> - Rob
> .
> 
> 
> 
> 


-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de