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

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

[Nick Clifton]

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 ?

Cheers
   Nick

Re: 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

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

[Nick Clifton]

Hi Jan,

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

Does the application link with "-z execstack" ?  If not, why not ?

Just curious really.  I want to know if there are likely to be other
apps out there that use executable stacks, but do not explicitly request
the feature from the linker.

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

Yeah - after thinking about this a bit more, I agree with you.  I think that
the best thing to do for now would be to extend the new warning message about
automatically created execstacks so that it also says that the feature is going
to be deprecated and then make the change in a couple of releases time.

Cheers
   Nick

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

[Jan Beulich]

On 21.04.2022 16:44, Nick Clifton wrote:
>>>     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 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. 
> 
> Does the application link with "-z execstack" ?  If not, why not ?
> 
> Just curious really.  I want to know if there are likely to be other
> apps out there that use executable stacks, but do not explicitly request
> the feature from the linker.

It doesn't, presumably simply because so far there was no need. The
tool may also pre-date the introduction of "-z execstack".

Jan

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

[Andreas Schwab]

On Apr 21 2022, Nick Clifton via Binutils wrote:

>   Other targets such as AArch64 and PowerPC do not this.  Instead they
>   just ignore object files with missing .note.GNU-stack sections.

They don't ignore them, they just use a different default.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Michael Matz]

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.

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

[Andreas Schwab]

On Apr 21 2022, Michael Matz via Binutils wrote:

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

That would only be needed if the compiler produces object files without
an explicit stack note on platforms where executable stacks are the
default.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Nick Clifton]

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

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

[Michael Matz]

Hello Nick,

On Fri, 22 Apr 2022, Nick Clifton wrote:

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

Yes, and as my (obviously too long-winded) reply tried to indicate I'm 
fine with that.

What I would not have been fine (and I'm aware that this wasn't proposed!) 
is if users always need -z execstack, i.e. if input .note.GNU-STACK 
sections were ignored and declared obsolete.  I only state that so 
explicitely because sometimes people on the net claim that taking these 
sections into account is a security hole as well, because "just including 
a random object file with a marker for executable stack makes the program 
insecure without the programmer being aware".


Ciao,
Michael.

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

[Martin Liška]

On 4/21/22 13:28, Nick Clifton via Binutils wrote:
> 
>    PR 29072 has brought up the issue of executable stacks.
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=29075

Hi.

This should be PR29072:
https://sourceware.org/bugzilla/show_bug.cgi?id=29072

which was originally discussed in mold issue:
https://github.com/rui314/mold/issues/427

Martin

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

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]



> On 21 Apr 2022, at 12:28, Nick Clifton via Binutils <binutils@sourceware.org> 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.

If you're looking for a softer approach, I'd consider a configure argument
to make this default so we can easily test it downstream
and see how bad the damage is.

But I'm supportive of the change either way, just might mean more work
fixing software :)

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

Absolutely.

> 

Best,
sam

>  Thoughts ?
> 
> Cheers
>  Nick
> 


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]