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

Nick Clifton nickc@redhat.com
Fri Apr 22 11:11:07 GMT 2022


Hi Michael,

> But a linker should not be limited to only one language.

Agrred.  Linkers must be language agnostic.

> There is Fortran
> for instance which _has_ nested functions that can be (sort-of)
> address-taken, and hence need trampolines somewhere.  There is Ada, there
> are other languages as well.  Requiring users using standard mandated
> functionality to add linker options just so that their programs work would
> be considered a bug in the toolchain by me, no matter if that "improves
> security".

But there is an already working method by which compilers can tell
the linker that an executable stack is needed - the .note-GNU_STACK
section.  So if compiler consistently use that feature, there is no
need for users to get involved at all.

What I am proposing for the BFD linker is to change a feature whereby
an object file which does not have a .note.GNU-STACK section will also
cause the creation of an executable stack - but only for certain
architectures.  On the AArch64 or PowerPC for example, the absence of
a .note-GNU_STACK section will not trigger the creation of an executable
stack.

So for an application to be affected by the change it would have to:

   * be restricted to architectures that default to an executable stack.

   * be compiled by a compiler that does not generate .note.GNU_STACK
     sections and/or contains assembler source code that does not include
     the provision of a .note.GNU_STACK section.

   * use a feature of the language(s) that actually requires an executable
     stack in order to work.

   * not add the "-z execstack" option to the linker command line when
     being built.

It is my hope that this will only be a small number of applications, but
even if it is not, proving a warning message about the proposed change in
behaviour for the next couple of releases of the binutils ought to be
sufficient to allow application builders to adapt.

Cheers
   Nick




More information about the Binutils mailing list