On Mon, Oct 24, 2016 at 5:56 AM Allan McRae <[email protected]> wrote:
> Hi all, > > The results from the test-sec-flags [1] 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 > exploitable. > > 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. > > Cheers, > Allan > Will this affect i686 as well? According to this commit ( https://github.com/zen-kernel/zen-kernel/commit/cc701dc61a7187e9dfc300ad6ec3b7a677dc4717) at least Ubuntu seems to have skipped that for now.
