Extend default compiler settings to harden applications

[Manthey, Norbert]

Hi all,

I would like to propose hardening Fedora artifacts by extending the default compilation flags. In the past, using the flags would have prevented or revealed CVEs or logic bugs.

In Amazon Linux we have been looking into changing the default compiler flags. Specifically, we looked at adding the below:

-fno-strict-overflow
  -fno-strict-aliasing
  -fno-delete-null-pointer-checks

For these flags, we did not see significant changes in performance tests. We found a few packages where the additional flags caused build errors, and submitted fixed to the respective packages.

What's a good process to get the flags into the redhat-rpm-config package, e.g. via a new macro that could be overriden by specific spec files in case the flags should not be used? Is there more information I should provide? Would there be another process for other flags, like -ftrivial-auto-var-init=zero where there can be minor performance consequences?

Best,
Norbert

[Simon de Vlieger]

On Fri, Aug 14, 2026, at 9:43 AM, Manthey, Norbert via devel wrote:
> Hi all,

Hi,
> I would like to propose hardening Fedora artifacts by extending the 
> default compilation flags. In the past, using the flags would have 
> prevented or revealed CVEs or logic bugs.
>
> In Amazon Linux we have been looking into changing the default compiler 
> flags. Specifically, we looked at adding the below:
>
> -fno-strict-overflow
>   -fno-strict-aliasing
>   -fno-delete-null-pointer-checks
>
> For these flags, we did not see significant changes in performance 
> tests. We found a few packages where the additional flags caused build 
> errors, and submitted fixed to the respective packages.
>
> What's a good process to get the flags into the redhat-rpm-config 
> package, e.g. via a new macro that could be overriden by specific spec 
> files in case the flags should not be used? Is there more information I 
> should provide? Would there be another process for other flags, like 
> -ftrivial-auto-var-init=zero where there can be minor performance 
> consequences?

This would go through the change process (system-wide) [1]. You could
propose the change for Fedora 46.

Regards,

Simon

[1]: https://docs.fedoraproject.org/en-US/operations/changes_guide/

[Christoph Erhardt]

Hi Norbert,

this sounds a sensible initiative to me.

Do you have more information to share? Areas of interest:
* concrete numbers from the performance measurements,
* number and names of packages that required fixing,
* their upstream status.

In principle I see two possible ways for introducing the new flags:
a) Append them to `_hardening_cflags` if we consider them generic hardening 
options that should be set for every hardened build.
b) Allow more fine-grained control by introducing an extra macro, similar to 
e.g. `_include_frame_pointers`.

I'm not sure which is preferable here.

Regarding `-ftrivial-auto-var-init=zero`: this is best done as a separate 
effort because its implications are somewhat more invasive from what I know.

Thanks,
Christoph

On Friday, 14 August 2026 09:43:44 Central European Summer Time Manthey, 
Norbert via devel wrote:
> Hi all,
>
> I would like to propose hardening Fedora artifacts by extending the default
> compilation flags. In the past, using the flags would have prevented or
> revealed CVEs or logic bugs.
>
> In Amazon Linux we have been looking into changing the default compiler
> flags. Specifically, we looked at adding the below:
>
> -fno-strict-overflow
>   -fno-strict-aliasing
>   -fno-delete-null-pointer-checks
>
> For these flags, we did not see significant changes in performance tests. We
> found a few packages where the additional flags caused build errors, and
> submitted fixed to the respective packages.
>
> What's a good process to get the flags into the redhat-rpm-config package,
> e.g. via a new macro that could be overriden by specific spec files in case
> the flags should not be used? Is there more information I should provide?
> Would there be another process for other flags, like
> -ftrivial-auto-var-init=zero where there can be minor performance
> consequences?
>
> Best,
> Norbert

[Christoph Erhardt]

On second thought, maybe 'hardening' isn't the most apt category to file these 
flags under. They are not so much about mitigating common exploitation 
techniques and more about preventing the compiler from being too clever in the 
optimisations it applies.

Best regards,
Christoph

On Sunday, 16 August 2026 16:28:20 Central European Summer Time Christoph 
Erhardt wrote:
> Hi Norbert,
>
> this sounds a sensible initiative to me.
>
> Do you have more information to share? Areas of interest:
> concrete numbers from the performance measurements,
> number and names of packages that required fixing,
> their upstream status.
>
> In principle I see two possible ways for introducing the new flags:
> a) Append them to `_hardening_cflags` if we consider them generic hardening
> options that should be set for every hardened build.
> b) Allow more fine-grained control by introducing an extra macro, similar to
> e.g. `_include_frame_pointers`.
>
> I'm not sure which is preferable here.
>
> Regarding `-ftrivial-auto-var-init=zero`: this is best done as a separate
> effort because its implications are somewhat more invasive from what I know.
>
> Thanks,
> Christoph

[Manthey, Norbert]

Thanks Christoph,

I will draft two independent change proposals with more details and will ping in case I need help to fill in the Fedora project specific details.

Best,
Norbert

________________________________
From: Christoph Erhardt
Sent: Monday, August 17, 2026 8:30 AM
To: [e-mail]
Cc: Manthey, Norbert
Subject: RE: [EXTERNAL] Extend default compiler settings to harden applications

On second thought, maybe 'hardening' isn't the most apt category to file these
flags under. They are not so much about mitigating common exploitation
techniques and more about preventing the compiler from being too clever in the
optimisations it applies.

Best regards,
Christoph

On Sunday, 16 August 2026 16:28:20 Central European Summer Time Christoph
Erhardt wrote:
> Hi Norbert,
>
> this sounds a sensible initiative to me.
>
> Do you have more information to share? Areas of interest:
> concrete numbers from the performance measurements,
> number and names of packages that required fixing,
> their upstream status.
>
> In principle I see two possible ways for introducing the new flags:
> a) Append them to `_hardening_cflags` if we consider them generic hardening
> options that should be set for every hardened build.
> b) Allow more fine-grained control by introducing an extra macro, similar to
> e.g. `_include_frame_pointers`.
>
> I'm not sure which is preferable here.
>
> Regarding `-ftrivial-auto-var-init=zero`: this is best done as a separate
> effort because its implications are somewhat more invasive from what I know.
>
> Thanks,
> Christoph

[Daniel P. Berrangé]

On Sun, Aug 16, 2026 at 04:28:20PM +0200, Christoph Erhardt wrote:
> Hi Norbert,
>
> this sounds a sensible initiative to me.
>
> Do you have more information to share? Areas of interest:
> concrete numbers from the performance measurements,
> number and names of packages that required fixing,
> their upstream status.
>
> In principle I see two possible ways for introducing the new flags:
> a) Append them to `_hardening_cflags` if we consider them generic hardening 
> options that should be set for every hardened build.
> b) Allow more fine-grained control by introducing an extra macro, similar to 
> e.g. `_include_frame_pointers`.
>
> I'm not sure which is preferable here.
>
> Regarding `-ftrivial-auto-var-init=zero`: this is best done as a separate 
> effort because its implications are somewhat more invasive from what I know.

snip
> > Would there be another process for other flags, like
> > -ftrivial-auto-var-init=zero where there can be minor performance
> > consequences?

"minor performance consequences" really depends on your POV of what
"minor" means.

Upstream we enabled -ftrivial-auto-var-init=zero unconditionally in
QEMU and found that virtio-blk degraded by 9%. In something where we
fight for every single 1% of performance, a 9% loss is major.

We can expect to see many examples of this across the Fedora package set
which will require maintainer attention if -ftrivial-auto-var-init=zero
is always enabled by default in Fedora CFLAGS.

Either maintainers will need to turn off the new flag or will need
to patch the code to add __attribute__((uninitialized)) against
variables that are performance sensitive. The latter is the best
option and what QEMU did upstream but much more work.

None the less I encourage wide adoption of -ftrivial-auto-var-init=zero
because it eliminates a whole class of vulnerabilities that the AI
powered security scanners otherwise complain about. This is more a
thing for upstream though.

With regards,
Daniel

[Jakub Jelinek]

On Fri, Aug 14, 2026 at 07:43:44AM +0000, Manthey, Norbert via devel wrote:
> I would like to propose hardening Fedora artifacts by extending the default compilation flags. In the past, using the flags would have prevented or revealed CVEs or logic bugs.
>
> In Amazon Linux we have been looking into changing the default compiler flags. Specifically, we looked at adding the below:
>
> -fno-strict-overflow
>   -fno-strict-aliasing
>   -fno-delete-null-pointer-checks

This is an extremely bad idea.

None of these flags are meant to be hardening options and none of those
are suitable for it.

-fno-strict-overflow (aka -fwrapv -fwrapv-pointer) simply selects different
behavior for signed overflows (wrapping rather than UB) and with that kills
significant amount of performance (all the loop optimizations that rely on
wrapping not happening, which is most of them; on some code it can result in
slowing performance sensitive code (inner loops) several times
(vectorization will not happen, loops will not be split, unswitched, number
of iterations analysis will not be able to figure out number of iterations,
...).
When signed arithmetic overflow happens, unless wrapping is what you
actually intend in that case (for that case sanely written code uses already
__builtin_*_overflow/<stdckdint.h> or <cstdckdint> APIs or casts to
corresponding integer types or if it is the intended behavior in whole
source file explicitly uses -fwrapv), simply wrapping will still mean the
code does something wrong anyway.  Code which assumes wrapping behavior uses
-fwrapv already, sanely written code doesn't need it.
Recommendation, just use -fsanitize=undefined when developing code and fix
any cases where it reports problems.

-fno-strict-aliasing is a workaround for really badly written code, most of
the code in the distro doesn't need it, badly written code which needs it
most likely already uses it.  And again, it will come with significant
penalization of properly written code, it will significantly affect
instruction scheduling, dead store elimination, full/partial redundancy
optimization etc.  For this case there is no sanitization (at least in GCC),
but there are warning options (-Wstrict-aliasing=*) which can warn about
problematic code.

-fno-delete-null-pointer-checks is an option meant for bare metal targets
where one can and often does have memory at address 0 and accessing data
at that address is needed.  Linux normally doesn't even allow mapping
pages at that address (except for priviledged processes or after tweaking
sysctl), so there is really no point in trying to support code that will
have variables at address 0.  Furthermore, turning this option on will
break significant amount of valid C++ code where the standard requires
to constant evaluate comparisons of addresses of objects against the
null pointer, but with -fno-delete-null-pointer-checks that can't be
supported because variables with that option actually can have their
address equal to the null pointer.  Sure, bootloaders or whatever can
have variables at that address needs to use this option, but normal userland
programs should not.

Jakub

[Christoph Erhardt]

On Wednesday, 2 September 2026 13:30:36 Central European Summer Time Jakub 
Jelinek via devel wrote:
> kills significant amount of performance
> (...)
> significant penalization of properly written code, it will significantly
> affect instruction scheduling, dead store elimination, full/partial
> redundancy optimization etc.
> (...)
> will break significant amount of valid C++ code

Oof, these are strongly worded concerns coming from the GCC team - thanks for 
raising them. I'd be interested to see Amazon backing up their claims to the 
contrary with concrete data.

On Friday, 14 August 2026 09:43:44 Central European Summer Time Manthey, 
Norbert via devel wrote:
> For these flags, we did not see significant changes in performance tests. We
> found a few packages where the additional flags caused build errors, and
> submitted fixed to the respective packages.

Christoph