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
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
