From: Marek Polacek <polacek@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: iain@sandoe.co.uk, GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH v3] gcc: Introduce -fhardened
Date: Tue, 24 Oct 2023 15:09:31 -0400 [thread overview]
Message-ID: <ZTgWa22mINvmS+sZ@redhat.com> (raw)
In-Reply-To: <CAFiYyc384kFW0sY2298+8yt8FDwiPhW160oCTo3EpxxZXMoa3g@mail.gmail.com>
On Tue, Oct 24, 2023 at 09:22:25AM +0200, Richard Biener wrote:
> On Mon, Oct 23, 2023 at 9:26 PM Marek Polacek <polacek@redhat.com> wrote:
> >
> > On Thu, Oct 19, 2023 at 02:24:11PM +0200, Richard Biener wrote:
> > > On Wed, Oct 11, 2023 at 10:48 PM Marek Polacek <polacek@redhat.com> wrote:
> > > >
> > > > On Tue, Sep 19, 2023 at 10:58:19AM -0400, Marek Polacek wrote:
> > > > > On Mon, Sep 18, 2023 at 08:57:39AM +0200, Richard Biener wrote:
> > > > > > On Fri, Sep 15, 2023 at 5:09 PM Marek Polacek via Gcc-patches
> > > > > > <gcc-patches@gcc.gnu.org> wrote:
> > > > > > >
> > > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, powerpc64le-unknown-linux-gnu,
> > > > > > > and aarch64-unknown-linux-gnu; ok for trunk?
> > > > > > >
> > > > > > > -- >8 --
> > > > > > > In <https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628748.html>
> > > > > > > I proposed -fhardened, a new umbrella option that enables a reasonable set
> > > > > > > of hardening flags. The read of the room seems to be that the option
> > > > > > > would be useful. So here's a patch implementing that option.
> > > > > > >
> > > > > > > Currently, -fhardened enables:
> > > > > > >
> > > > > > > -D_FORTIFY_SOURCE=3 (or =2 for older glibcs)
> > > > > > > -D_GLIBCXX_ASSERTIONS
> > > > > > > -ftrivial-auto-var-init=pattern
> > >
> > > I think =zero is much better here given the overhead is way
> > > cheaper and pointers get a more reliable behavior.
> >
> > Ok, changed now.
> >
> > > > > > > -fPIE -pie -Wl,-z,relro,-z,now
> > > > > > > -fstack-protector-strong
> > > > > > > -fstack-clash-protection
> > > > > > > -fcf-protection=full (x86 GNU/Linux only)
> > > > > > >
> > > > > > > -fhardened will not override options that were specified on the command line
> > > > > > > (before or after -fhardened). For example,
> > > > > > >
> > > > > > > -D_FORTIFY_SOURCE=1 -fhardened
> > > > > > >
> > > > > > > means that _FORTIFY_SOURCE=1 will be used. Similarly,
> > > > > > >
> > > > > > > -fhardened -fstack-protector
> > > > > > >
> > > > > > > will not enable -fstack-protector-strong.
> > > > > > >
> > > > > > > In DW_AT_producer it is reflected only as -fhardened; it doesn't expand
> > > > > > > to anything. I think we need a better way to show what it actually
> > > > > > > enables.
> > > > > >
> > > > > > I do think we need to find a solution here to solve asserting compliance.
> > > > >
> > > > > Fair enough.
> > > > >
> > > > > > Maybe we can have -Whardened that will diagnose any altering of
> > > > > > -fhardened by other options on the command-line or by missed target
> > > > > > implementations? People might for example use -fstack-protector
> > > > > > but don't really want to make protection lower than requested with -fhardened.
> > > > > >
> > > > > > Any such conflict is much less appearant than when you use the
> > > > > > flags -fhardened composes.
> > > > >
> > > > > How about: --help=hardened says which options -fhardened attempts to
> > > > > enable, and -Whardened warns when it didn't enable an option? E.g.,
> > > > >
> > > > > -fstack-protector -fhardened -Whardened
> > > > >
> > > > > would say that it didn't enable -fstack-protector-strong because
> > > > > -fstack-protector was specified on the command line?
> > > > >
> > > > > If !HAVE_LD_NOW_SUPPORT, --help=hardened probably doesn't even have to
> > > > > list -z now, likewise for -z relro.
> > > > >
> > > > > Unclear if -Whardened should be enabled by default, but probably yes?
> > > >
> > > > Here's v2 which adds -Whardened (enabled by default).
> > > >
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > >
> > > I think it's OK but I'd like to see a second ACK here.
> >
> > Thanks!
> >
> > > Can you see how our
> > > primary and secondary targets (+ host OS) behave here?
> >
> > That's very reasonable. I tried to build gcc on Compile Farm 119 (AIX) but
> > that fails with:
> >
> > ar -X64 x ../ppc64/libgcc/libgcc_s.a shr.o
> > ar: 0707-100 ../ppc64/libgcc/libgcc_s.a does not exist.
> > make[2]: *** [/home/polacek/gcc/libgcc/config/rs6000/t-slibgcc-aix:98: all] Error 1
> > make[2]: Leaving directory '/home/polacek/x/trunk/powerpc-ibm-aix7.3.1.0/libgcc'
> >
> > and I tried Darwin (104) and that fails with
> >
> > *** Configuration aarch64-apple-darwin21.6.0 not supported
> >
> > Is anyone else able to build gcc on those machines, or test the attached
> > patch?
> >
> > > I think the
> > > documentation should elaborate a bit on expectations for non-Linux/GNU
> > > targets, specifically I think the default configuration for a target should
> > > with -fhardened _not_ have any -Whardened diagnostics. Maybe we can
> > > have a testcase for this?
> >
> > Sorry, I'm not sure how to test that. I suppose if -fhardened enables
> > something not supported on those systems, and it's something for which
> > we have a configure test, then we shouldn't warn. This is already the
> > case for -pie, -z relro, and -z now.
>
> I was thinking of
>
> /* { dg-do compile } */
> /* { dg-additional-options "-fhardened -Whardened" } */
>
> int main () {}
>
> and excess errors should catch "misconfigurations"?
I see. fhardened-3.c is basically just like this (-Whardened is on by default).
> > Should the docs say something like the following for features without
> > configure checks?
> >
> > @option{-fhardened} can, on certain systems, attempt to enable features
> > not supported on that particular system. In that case, it's possible to
> > prevent the warning using the @option{-Wno-hardened} option.
>
> Yeah, but ideally
>
> @option{-fhardened} can, on certain systems, not enable features not
> available on those systems and @option{-Whardened} will not diagnose
> those as missing.
>
> But I understand it doesn't work like that?
Right. It will not diagnose missing features if they have a configure
check, otherwise it will. And I don't know if we want a configure check
for every feature. Maybe we can add them in the future if the current
patch turns out to be problematical in practice?
Thanks,
Marek
next prev parent reply other threads:[~2023-10-24 19:09 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-15 15:08 [PATCH] " Marek Polacek
2023-09-18 6:57 ` Richard Biener
2023-09-19 14:58 ` Marek Polacek
2023-09-19 15:14 ` Jakub Jelinek
2023-10-11 20:48 ` [PATCH v2] " Marek Polacek
2023-10-18 20:12 ` Qing Zhao
2023-10-19 18:32 ` Marek Polacek
2023-10-19 12:24 ` Richard Biener
2023-10-19 12:33 ` Sam James
2023-10-19 18:33 ` Marek Polacek
2023-10-23 19:25 ` [PATCH v3] " Marek Polacek
2023-10-24 7:22 ` Richard Biener
2023-10-24 19:09 ` Marek Polacek [this message]
2023-10-26 15:55 ` Richard Biener
2023-11-03 22:51 ` [PATCH v4] " Marek Polacek
2023-11-13 15:41 ` Marek Polacek
2023-11-14 7:46 ` Richard Biener
2023-11-14 16:00 ` Marek Polacek
2023-11-15 11:42 ` Richard Biener
2023-11-15 12:25 ` Jakub Jelinek
2023-11-16 20:51 ` [PATCH v5] " Marek Polacek
2023-11-20 16:32 ` Jakub Jelinek
2023-11-21 15:41 ` Marek Polacek
2023-11-23 16:59 ` Marek Polacek
2023-10-24 7:44 ` [PATCH v3] " Iain Sandoe
2023-10-24 9:34 ` Iain Sandoe
2023-10-24 19:03 ` Marek Polacek
2023-10-24 19:16 ` Iain Sandoe
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=ZTgWa22mINvmS+sZ@redhat.com \
--to=polacek@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=iain@sandoe.co.uk \
--cc=richard.guenther@gmail.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).