Fix hppa/ia64/microblaze executable stack default (bug 22156)

[Joseph Myers]

On Tue, 19 Sep 2017, Carlos O'Donell wrote:

> On 09/19/2017 08:54 AM, Andreas Schwab wrote:
> > It's the absence of the note that is relevant here.
> 
> It can't be safe to override this?
> 
> This breaks backwards compatibility with old binaries that don't have PT_GNU_STACK
> but need executable stacks?
> 
> I thought perhaps we were arguing to make old binaries
> safer, at the risk of breaking some of them.

My understanding is:

(a) As per Andreas, the kernel defaults to non-executable stacks on these 
three architectures.

(b) That is, if ld.so has no PT_GNU_STACK, the stack is non-executable; if 
ld.so does have PT_GNU_STACK, the kernel sets the permissions on the stack 
accordingly (which can include making it executable for trampoline use 
when the default is non-executable).

(c) At present, these GCC ports will never create PT_GNU_STACK markings to 
indicate that a trampoline needs an executable stack (if it does).

(d) glibc presumes that the kernel set the stack permissions to 
DEFAULT_STACK_PERMS.  If the executable or a loaded shared library 
introduces an executable stack requirement, the dynamic linker can make 
the stack executable - but it will never do so if it thinks the kernel 
already did so.

(e) DEFAULT_STACK_PERMS is used when creating thread stacks.

Now, if trampolines need executable stacks (and in some cases, especially 
with function descriptors, they may not) but work at present on those 
architectures with the default stack (rather than a thread stack), that 
suggests there is something wrong with the above analysis.

-- 
Joseph S. Myers
joseph@codesourcery.com