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

[Michael Matz <matz@suse.de>]

Hey,

On Thu, 21 Apr 2022, 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

As (too long) pre-text:

This came about by Martin of us testing mold distro-wide and seeing issues 
with some packages.  Then there was discussion about how mold's behaviour 
is "more secure" and the resulting bug above to also make GNU ld "more 
secure".

I fear there is some language-centricism at play, especially when arguing 
that "(address-taking of) nested functions are rare" and hence "people 
ought to have to use linker options to make them work".

If we were talking only about C and C++ that all would make sense.  
After all, those languages don't have nested functions, hence no 
address-taking of them, and hence no need for executable stack (or more 
generally any executable memory in arbitrary supply).  That GNU C allows 
them is an extension, and requiring people using that extension to use an 
explicit linker option seems acceptable.

But a linker should not be limited to only one language.  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".

Hence, the only acceptable way IMHO is for the linker to automatically 
mark the stack executable if requested implicitely by the compiler.  
Currently there's only one granularity by which it can be requested: per 
object file by the .note.GNU-stack section.  Other granularities could be 
imagined (per symbol for instance, or somesuch), but that's not on the 
table, and wouldn't shift the responsibility away from the compiler 
anyway.

So, with that out of the way, let's see ...

>   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.

... so that matches my minimum expectations of the toolchain: that stuff 
can be made to work out of box.  As long as the compiler can explicitely 
request an exec stack, and doesn't need to rely on the user to do so, I'm 
fine from a distro (and user) perspective.

Giving a message to the effect of enabling exec-stack due to object file 
such-and-such seems acceptable as well.

So, the proposal as above (exec-stack due to explicit .note.GNU-stack, or 
due to cmdline option) looks okay IMO.  In particular removing the feature 
of having exec-stack due to missing .note.GNU-stack sections in input 
files, even on x86-64, looks okay as well, even if that requires some 
churn in some packages.

>   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.

On this I disagree, as per above.  If I'm using standard features of my 
language of choice I'm going to be non-plussed if that required linker 
options.


Ciao,
Michael.