public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Sam James <sam@gentoo.org>
To: Nick Clifton <nickc@redhat.com>
Cc: Binutils <binutils@sourceware.org>, toolchain@gentoo.org
Subject: Re: RFC: Should we have all targets default to only creating an executable stack when explicitly requested ?
Date: Mon, 25 Apr 2022 14:46:37 +0100	[thread overview]
Message-ID: <73BB2FC1-5443-4875-9567-DCBD09A58B1E@gentoo.org> (raw)
In-Reply-To: <51664b3e-9dbd-65e2-00b3-7f7842f76ed4@redhat.com>

[-- 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 --]

      parent reply	other threads:[~2022-04-25 13:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-21 11:28 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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=73BB2FC1-5443-4875-9567-DCBD09A58B1E@gentoo.org \
    --to=sam@gentoo.org \
    --cc=binutils@sourceware.org \
    --cc=nickc@redhat.com \
    --cc=toolchain@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).