RFC: Should we have all targets default to only creating an executable stack when explicitly requested ?

[Jan Beulich]

On 21.04.2022 13:28, Nick Clifton via Binutils wrote:
> Hi Guys,
> 
>     PR 29072 has brought up the issue of executable stacks.
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=29075
> 
>    Currently the bfd linker will create an executable stack if explicitly
>    requested to do so, either via the '-z execstack' option, or via the
>    presence of a .note-GNU-stack section which has the SHF_EXECINSTR flag
>    set.
> 
>    In addition, for targets like the x86_64 and s390x the linker will also
>    create an executable stack if any linked object file does not have a
>    .note.GNU-stack section.  (Such an occurrence is especially common for
>    hand crafted assembler source files).  This can result in programs
>    gaining an executable stack even when the user is not expecting it.
> 
>    Other targets such as AArch64 and PowerPC do not this.  Instead they
>    just ignore object files with missing .note.GNU-stack sections.
> 
>    A proposal has been made that all targets should ignore missing
>    .note.GNU-stack sections, and the linker should only ever create an
>    executable stack if explicitly requested by one of the two methods
>    described in the second paragraph.  I am inclined to agree with this
>    proposal, but I would like to see if anyone has any objections or
>    comments first.
> 
>    It is possible that such a change will break applications that rely
>    upon the current behaviour.  But, in my opinion, this would actually
>    be a good thing.  Applications with an executable stack are a security
>    risk, and they ought to be reviewed.  If an exectuable stack really
>    is needed then it can be explicitly requested via the '-z execstack'
>    command line option.
> 
>    Thoughts ?

I know of such an application right away. It being used merely for testing
purposes, I believe it's okay-ish to have an executable stack. But what
I'd like to avoid is that someone would need to be forced to take immediate
action because of such changed behavior. Hence I'd like to suggest that for
at least one (better two or three) major releases there be merely a warning
that the behavior will change, giving people time to silence the warning
while being able to continue to do their immediate work.

Jan