public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Binutils <binutils@sourceware.org>
Subject: Re: RFC: Should we have all targets default to only creating an executable stack when explicitly requested ?
Date: Thu, 21 Apr 2022 15:44:20 +0100	[thread overview]
Message-ID: <c99c5c3d-479a-aa75-4ce6-dd798d513686@redhat.com> (raw)
In-Reply-To: <3233e8f4-4baa-9cb7-c86e-a60e8f7116f4@suse.com>

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


  reply	other threads:[~2022-04-21 14:44 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 [this message]
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

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=c99c5c3d-479a-aa75-4ce6-dd798d513686@redhat.com \
    --to=nickc@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=jbeulich@suse.com \
    /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).