public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "noloader at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/103863] New: We need a warning for loss of no-exec stacks
Date: Thu, 30 Dec 2021 01:59:55 +0000	[thread overview]
Message-ID: <bug-103863-4@http.gcc.gnu.org/bugzilla/> (raw)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103863

            Bug ID: 103863
           Summary: We need a warning for loss of no-exec stacks
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: noloader at gmail dot com
  Target Milestone: ---

Hello,

This is a feature request.

For targets that support no-exec stacks, we need a warning when GCC generates
code or drives the linker with loss of no-exec stacks.

The warning would be beneficial for most builds nowadays since no-exec stacks
are part of most distro hardening. For example, Debian and Fedora both
incorporate it into their build system; and special steps must be taken to
avoid no-exec stacks out of the box.

The warning would also be beneficial in cases like
https://bugzilla.redhat.com/show_bug.cgi?id=2035802. In the 2035802 bug, an ARM
machine failed to boot because libz contained executable stacks even though
they were not needed.

A specific warning for no-exec stacks is slightly different than -Wtrampolines.
While trampolines resulted in executable stacks in the past, that may not hold
in the future as lambdas are added to the language. And trampolines are not a
necessary precondition to get in an insecure state like the 2035802 bug shows.

It is most unfortunate that ASM files need special handling because the object
files are marked with executable stacks by default. Maybe that should be
another bug report to change default behavior since the strategy nowadays is:
no-exec stacks by default, do something special for executable stacks.

Thanks in advance.

             reply	other threads:[~2021-12-30  1:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-30  1:59 noloader at gmail dot com [this message]
2021-12-30  2:04 ` [Bug driver/103863] " pinskia at gcc dot gnu.org
2021-12-30  2:05 ` pinskia at gcc dot gnu.org
2021-12-30  2:27 ` noloader at gmail dot com

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=bug-103863-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.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).