[arch-dev-public] Changing compilation flags
allan at archlinux.org
Mon Oct 24 03:56:14 UTC 2016
The results from the test-sec-flags  suite are in. Many thanks to
those that wrote this and those that submitted results. I'm not going
to list the summaries here, but the results show that at worst enabling
a bunch of security flags in our packages will have a <1% impact on
performance (and more likely a fraction of a percent).
That means we will add all of these to our default CFLAGS/LDFLAGS etc.
The changes are:
1) building gcc to enable PIE by default
2) add -z,now to LDFLAGS
3) and -fno-plt and -fstack-check to our CFLAGS
Adding PIE means that programs get loaded at a random address,
preventing an attacker from manipulating global data or hijacking
control by reusing code. Without this, ASLR is ineffective. Enabling
this by default in our compiler (there is a configure flag) means we
will need to rebuild all packages with static libraries (which should be
a fairly limited set).
Adding -z,now to LDFLAGS disables lazy loading. This means all function
symbols are loaded at startup (with minor performance hit), but that
means our RELRO support will make everything ro instead of some of the
things. Doing this enables us to use -fno-plt in our CFLAGS, which is a
run-time optimisation allowing faster use of libraries.
Adding -fstack-check to our CFLAGS guarantees stack overflows aren't
Note that any of these flags can be disabled in a PKGBUILD if really
needed... But if that is the case, bug reports should be filed.
Given an assumed lack of objection, I will enable the build flags in our
pacman.conf and rebuild gcc to enable pie and put them in [staging] at
the end of this week (what better way to celebrate Halloween). We will
need a new devtools release then too. Then the packages with static
libraries will need rebuilt.
After that, I would like to see [core] completely rebuilt, and audited
to ensure our CFLAGS/LDFLAGS are actually being used in the build.
More information about the arch-dev-public