* RFC: Should we have all targets default to only creating an executable stack when explicitly requested ?
@ 2022-04-21 11:28 Nick Clifton
2022-04-21 11:44 ` Jan Beulich
` (4 more replies)
0 siblings, 5 replies; 11+ messages in thread
From: Nick Clifton @ 2022-04-21 11:28 UTC (permalink / raw)
To: Binutils
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Should we have all targets default to only creating an executable stack when explicitly requested ?
2022-04-21 11:28 RFC: Should we have all targets default to only creating an executable stack when explicitly requested ? Nick Clifton
@ 2022-04-21 11:44 ` Jan Beulich
2022-04-21 14:44 ` Nick Clifton
2022-04-21 11:52 ` Andreas Schwab
` (3 subsequent siblings)
4 siblings, 1 reply; 11+ messages in thread
From: Jan Beulich @ 2022-04-21 11:44 UTC (permalink / raw)
To: Nick Clifton; +Cc: Binutils
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Should we have all targets default to only creating an executable stack when explicitly requested ?
2022-04-21 11:28 RFC: Should we have all targets default to only creating an executable stack when explicitly requested ? Nick Clifton
2022-04-21 11:44 ` Jan Beulich
@ 2022-04-21 11:52 ` Andreas Schwab
2022-04-21 15:00 ` Michael Matz
` (2 subsequent siblings)
4 siblings, 0 replies; 11+ messages in thread
From: Andreas Schwab @ 2022-04-21 11:52 UTC (permalink / raw)
To: Nick Clifton via Binutils
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."
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Should we have all targets default to only creating an executable stack when explicitly requested ?
2022-04-21 11:44 ` Jan Beulich
@ 2022-04-21 14:44 ` Nick Clifton
2022-04-21 15:31 ` Jan Beulich
0 siblings, 1 reply; 11+ messages in thread
From: Nick Clifton @ 2022-04-21 14:44 UTC (permalink / raw)
To: Jan Beulich; +Cc: Binutils
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Should we have all targets default to only creating an executable stack when explicitly requested ?
2022-04-21 11:28 RFC: Should we have all targets default to only creating an executable stack when explicitly requested ? Nick Clifton
2022-04-21 11:44 ` Jan Beulich
2022-04-21 11:52 ` Andreas Schwab
@ 2022-04-21 15:00 ` Michael Matz
2022-04-21 16:00 ` Andreas Schwab
2022-04-22 11:11 ` Nick Clifton
2022-04-22 11:41 ` Martin Liška
2022-04-25 13:46 ` Sam James
4 siblings, 2 replies; 11+ messages in thread
From: Michael Matz @ 2022-04-21 15:00 UTC (permalink / raw)
To: Nick Clifton; +Cc: Binutils
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Should we have all targets default to only creating an executable stack when explicitly requested ?
2022-04-21 14:44 ` Nick Clifton
@ 2022-04-21 15:31 ` Jan Beulich
0 siblings, 0 replies; 11+ messages in thread
From: Jan Beulich @ 2022-04-21 15:31 UTC (permalink / raw)
To: Nick Clifton; +Cc: Binutils
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Should we have all targets default to only creating an executable stack when explicitly requested ?
2022-04-21 15:00 ` Michael Matz
@ 2022-04-21 16:00 ` Andreas Schwab
2022-04-22 11:11 ` Nick Clifton
1 sibling, 0 replies; 11+ messages in thread
From: Andreas Schwab @ 2022-04-21 16:00 UTC (permalink / raw)
To: Michael Matz via Binutils
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."
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Should we have all targets default to only creating an executable stack when explicitly requested ?
2022-04-21 15:00 ` Michael Matz
2022-04-21 16:00 ` Andreas Schwab
@ 2022-04-22 11:11 ` Nick Clifton
2022-04-25 13:25 ` Michael Matz
1 sibling, 1 reply; 11+ messages in thread
From: Nick Clifton @ 2022-04-22 11:11 UTC (permalink / raw)
To: Michael Matz; +Cc: Binutils
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Should we have all targets default to only creating an executable stack when explicitly requested ?
2022-04-21 11:28 RFC: Should we have all targets default to only creating an executable stack when explicitly requested ? Nick Clifton
` (2 preceding siblings ...)
2022-04-21 15:00 ` Michael Matz
@ 2022-04-22 11:41 ` Martin Liška
2022-04-25 13:46 ` Sam James
4 siblings, 0 replies; 11+ messages in thread
From: Martin Liška @ 2022-04-22 11:41 UTC (permalink / raw)
To: Nick Clifton, Binutils
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Should we have all targets default to only creating an executable stack when explicitly requested ?
2022-04-22 11:11 ` Nick Clifton
@ 2022-04-25 13:25 ` Michael Matz
0 siblings, 0 replies; 11+ messages in thread
From: Michael Matz @ 2022-04-25 13:25 UTC (permalink / raw)
To: Nick Clifton; +Cc: Binutils
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFC: Should we have all targets default to only creating an executable stack when explicitly requested ?
2022-04-21 11:28 RFC: Should we have all targets default to only creating an executable stack when explicitly requested ? Nick Clifton
` (3 preceding siblings ...)
2022-04-22 11:41 ` Martin Liška
@ 2022-04-25 13:46 ` Sam James
4 siblings, 0 replies; 11+ messages in thread
From: Sam James @ 2022-04-25 13:46 UTC (permalink / raw)
To: Nick Clifton; +Cc: Binutils, toolchain
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-04-25 13:46 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-21 11:28 RFC: Should we have all targets default to only creating an executable stack when explicitly requested ? Nick Clifton
2022-04-21 11:44 ` Jan Beulich
2022-04-21 14:44 ` Nick Clifton
2022-04-21 15:31 ` Jan Beulich
2022-04-21 11:52 ` Andreas Schwab
2022-04-21 15:00 ` Michael Matz
2022-04-21 16:00 ` Andreas Schwab
2022-04-22 11:11 ` Nick Clifton
2022-04-25 13:25 ` Michael Matz
2022-04-22 11:41 ` Martin Liška
2022-04-25 13:46 ` Sam James
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).