Re: [PATCH] gcc: Introduce -fhardened

[Jakub Jelinek <jakub@redhat.com>]

On Tue, Sep 19, 2023 at 10:58:19AM -0400, Marek Polacek wrote:
> > > 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
> > >   -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.

Well, asserting compliance doesn't make sense, because many of these features
are only best effort.  So, one can assert that certain options have been
passed to the compiler (or not), and for that the current
-grecord-gcc-switches I think works mostly fine (well, it doesn't record -D*
options), one knows the compiler version/snapshot date etc. and what options
have been passed and can by repeating those options see what is and isn't
enabled in that case.
As for what exact options are actually enabled in the end, --help should be
able to answer that.  Still, even if one records that -D_FORTIFY_SOURCE=3
was passed on the command line, that doesn't mean there is no
#undef _FORTIFY_SOURCE in the source before including headers, or that
the compiler has been successful to figure out object size (static or
dynamic) for certain pointer, or that a function has some array so that it
will use stack protector guard, or that certain function didn't disable
-fstack-protector through function attributes etc.
So, if one wants to know if certain vulnerability exploit can be stopped
through hardening, one needs to analyze actually emitted code, just looking
for checkboxes isn't enough.
One can assert -D_FORTIFY_SOURCE=2 has been passed, but without glibc
headers being used and actually using __builtin_*object_size it doesn't do
anything either.  Programs can just declare memcpy etc. themselves and not
include glibc headers...

If the checkboxes are desirable for some reason, perhaps we could introduce
a new DWARF DW_AT_GNU_hardening attribute which would contain say bitfield
of which of those hardening features have been enabled (though, not sure if
we want to emit them just per DW_TAG_compile_unit, or DW_TAG_subprogram,
or both (say put on DW_TAG_compile_unit always if at least one of those is
enabled and on DW_TAG_subprogram only if it is different from the CU one).

	Jakub