I need time to fix this.  It is probably just test suite assumptions rather than errors.

Could we start with the changes other than PIE? Those won't need any immediate rebuilds.

On 13/12/16 19:07, Allan McRae wrote:

On 24/10/16 13:56, Allan McRae wrote:

...

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

For those wondering what happened with this:

binutils build with gcc with default PIE:

# grep Error binutils-git-89080.bfbf34d-1-x86_64-check.log make[5]: *** [Makefile:7161: incremental_test_2] Error 1 make[5]: *** [Makefile:7185: incremental_test_5] Error 1 make[5]: *** [Makefile:7200: incremental_copy_test] Error 1 make[5]: *** [Makefile:7206: incremental_common_test_1] Error 1 make[5]: *** [Makefile:7132: ehdr_start_test_4] Error 1 readelf: Error: the PHDR segment is not covered by a LOAD segment make[4]: *** [Makefile:5609: check-am] Error 2 make[3]: *** [Makefile:5613: check] Error 2 make[2]: *** [Makefile:941: check-recursive] Error 1 make[1]: *** [Makefile:6134: check-gold] Error 2 make[5]: *** [Makefile:3678: check-DEJAGNU] Error 1 make[4]: *** [Makefile:1953: check-am] Error 2 make[3]: *** [Makefile:1793: check-recursive] Error 1 make[2]: *** [Makefile:1955: check] Error 2 make[1]: *** [Makefile:7547: check-ld] Error 2 make: *** [Makefile:2206: do-check] Error 2

binutils build with current gcc:

# grep Error binutils-git-89080.bfbf34d-1-x86_64-check.log readelf: Error: the PHDR segment is not covered by a LOAD segment

I need time to fix this. It is probably just test suite assumptions rather than errors.

I'm putting these changes on a permanent hold due to a lack of time on my behalf. I'm not putting a binutils build with this many testsuite failures into the repos until I fully understand why this is happening. If default PIE is wanted, someone other than me will need to figure this out. Just build gcc with --enable-default-pie and then build binutils to see the issues in the testsuite. Allan

On 02/02/17 05:06, Bartłomiej Piotrowski wrote:

On 2016-12-24 08:39, Allan McRae wrote:

...

If default PIE is wanted, someone other than me will need to figure this out. Just build gcc with --enable-default-pie and then build binutils to see the issues in the testsuite.

Allan

Default PIE is not everything you planned to implement. What about the rest?

Can't be fucked doing this twice. A

On 13/12/16 19:23, Jan Alexander Steffens via arch-dev-public wrote:

On Mon, Oct 24, 2016 at 5:56 AM Allan McRae 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/cc701dc61a7187e9dfc300ad6ec3...) at least Ubuntu seems to have skipped that for now.

That commit shows they disabled it for one package. It will affect both. A

On 30 June 2017 at 18:56, Daniel Micay via arch-dev-public wrote:

It's probably a good idea to leave it in CFLAGS for Clang.

I am planning to patch Clang to follow GCC's behavior similarly to what Alpine does. [1] We can discuss dropping the related compilation flags from makepkg.conf at a later stage. [1] https://git.alpinelinux.org/cgit/aports/tree/main/clang

On 30/06/17 22:22, Jelle van der Waa wrote:

On 06/30/17 at 09:49pm, Evangelos Foutras via arch-dev-public wrote:

...

On 30 June 2017 at 18:56, Daniel Micay via arch-dev-public wrote:

...

It's probably a good idea to leave it in CFLAGS for Clang.

I am planning to patch Clang to follow GCC's behavior similarly to what Alpine does. [1]

We can discuss dropping the related compilation flags from makepkg.conf at a later stage.

[1] https://git.alpinelinux.org/cgit/aports/tree/main/clang

Seeing that Arch is defined, will you upstream these changes? If so (+1)

I don't think special-casing distros is the right way to go for PIE and SSP; I would much rather see upstream add a CMake option for those. [1] I'll probably patch isPIEDefault() and GetDefaultStackProtectorLevel() to return true and 2 respectively; assuming it actually works and I am able to address any test failures. [1] https://bugs.llvm.org/show_bug.cgi?id=13410

On 2017-06-30 23:44, Allan McRae wrote:

On 30/06/17 19:07, Bartłomiej Piotrowski wrote:

...

On 2016-10-24 05:56, Allan McRae wrote:

...

1) building gcc to enable PIE by default

I am in the middle of rebuilding gcc with --enable-default-pie. When it finishes, I will start a todo for rebuilding packages with static libraries.

I also enabled --enable-default-ssp, which means that -fstack-protector-strong will be dropped from our CFLAGS (as it will be enforced by gcc) on the next opportunity.

Are you adding full RELRO + no-plt at the same time?

A

Yes, and -fstack-check=specific too, although I might drop no-plt if it will cause too many builders. Bartłomiej

On 2017-07-02 00:32, Allan McRae wrote:

On 02/07/17 06:51, Bartłomiej Piotrowski wrote:

...

On 2017-06-30 23:44, Allan McRae wrote:

...

On 30/06/17 19:07, Bartłomiej Piotrowski wrote:

...

On 2016-10-24 05:56, Allan McRae wrote:

...

1) building gcc to enable PIE by default

I am in the middle of rebuilding gcc with --enable-default-pie. When it finishes, I will start a todo for rebuilding packages with static libraries.

I also enabled --enable-default-ssp, which means that -fstack-protector-strong will be dropped from our CFLAGS (as it will be enforced by gcc) on the next opportunity.

Are you adding full RELRO + no-plt at the same time?

A

Yes, and -fstack-check=specific too, although I might drop no-plt if it will cause too many builders.

I thought the conclusion from the Stack Clash bugs was that the current -fstack-check was fundamentally flawed and was being completely rewritten for the next gcc. Is the "=specific" version OK?

Packages described in Qualys' analysis weren't affected if compiled with 'specific'. It's probably not perfect either, but better that than nothing at all. Bartłomiej

Anyway, I think -Wl,-z,now, --enable-default-pie and --enable-default- ssp are a good starting point. Could enable -fstack-check=specific now, but it's not going to save a mass rebuild by doing it now (if the goal is to rebuild everything important with it) because they'll be improving it. Using -fno-plt would be a nice tiny little performance boost at runtime but then it's important to make sure everything is compiled with -Wl,- z,now and there might be programs ignoring LDFLAGS but respecting CFLAGS. Ideally -z now would be the default in the linker first. If we aren't going to patch the default, then I think a configure flag for that needs to land upstream.

On 2017-07-05 11:36, Evangelos Foutras wrote:

On 2 July 2017 at 19:19, Daniel Micay via arch-dev-public wrote:

...

Using -fno-plt would be a nice tiny little performance boost at runtime but then it's important to make sure everything is compiled with -Wl,- z,now and there might be programs ignoring LDFLAGS but respecting CFLAGS. Ideally -z now would be the default in the linker first. If we aren't going to patch the default, then I think a configure flag for that needs to land upstream.

It's also worth noting that clang does not support the -fno-plt option and I couldn't find any discussions about adding support for it.

If it's only a tiny performance improvement, I strongly believe we should skip it for now.

Repeating what I said on IRC. First, it's easy to workaround - there is no magic about using bash substitution and re-exporting CFLAGS in the environment. Second, enabling PIE and SSP by default is already a breaking change that we make an exception for clang. Apparently you can patch clang to reflect this, but you can't make it ignore -fno-plt too? This is not a huge change that will cause everything to fall apart, and less than 40 packages need clang. I can live with having to change them. Bartłomiej

On 5 July 2017 at 19:51, Daniel Micay wrote:

On Wed, 2017-07-05 at 12:36 +0300, Evangelos Foutras wrote:

...

On 2 July 2017 at 19:19, Daniel Micay via arch-dev-public wrote:

...

Using -fno-plt would be a nice tiny little performance boost at runtime but then it's important to make sure everything is compiled with -Wl,- z,now and there might be programs ignoring LDFLAGS but respecting CFLAGS. Ideally -z now would be the default in the linker first. If we aren't going to patch the default, then I think a configure flag for that needs to land upstream.

It's also worth noting that clang does not support the -fno-plt option and I couldn't find any discussions about adding support for it.

If it's only a tiny performance improvement, I strongly believe we should skip it for now.

There's no loss of compatibility from only some code using it. The only issue with it is that immediate binding *must* be used to support it, so if CFLAGS is respected then LDFLAGS *must* be respected, or immediate binding needs to be set as the default in the linker(s).

By lacking support I meant that clang aborts the compilation and throws an error with -fno-plt: clang-4.0: error: unknown argument: '-fno-plt' I briefly discussed this on IRC with Bartłomiej and he finds it acceptable to add workarounds (removing -fno-plt from CFLAGS) to the few dozen packages that use clang for building (not counting AUR packages). I disagree and do not consider insignificant performance increases to be sufficient justification to add GCC 6+ specific options to the default CFLAGS and necessitate adding workarounds to packages that do not use the default compiler. And then there is the (minor) issue you highlight, and possibly other issues we don't know about (since -fno-plt hasn't been adopted by any other distro). On a related note, it is unclear to me whether you mean that packages might fail to build (and/or run?) if they only respect CFLAGS but not LDFLAGS, or that a package might fail to build (and/or run?) because one of its dependencies didn't respect LDFLAGS.

So I think it would be a good idea to flip the default to -z,now in the linker if we're going to use -fno-plt. I think they'd take a patch for that upstream. Clang issue could be avoided with a 1 line patch adding another no-op flag and they'd take that upstream. It's harmless to use the slower lazy linking calling convention when -fno-plt is passed.

This is literally just +1 LOC for Clang b/c it has a system for adding no-op flags already, which is mostly used for GCC compatibility. It even uses it in cases that are quite dubious like making -fstack- check into a no-op, despite it not just being an optional optimization / code generation change like -fno-plt.