[arch-general] Changing compilation flags

Bartłomiej Piotrowski bpiotrowski at archlinux.org
Thu Jul 13 06:29:27 UTC 2017


On 2017-07-12 18:25, Jordan Glover via arch-general wrote:
> I testes some rebuilded binaries and BINDNOW isn't always enabled:
> checksec -f /usr/bin/unrar
> RELRO
> Partial RELRO
> checksec -f /usr/bin/qml (qt5-declarative)
> RELRO
> Partial RELRO
> I don't know if -fno-plt was correctly passed but it's possible that build process doesn't work as intended. Maybe we need to patch binutils to enable z,now by default as Daniel advised?
> On Wed Jul 5 16:51:55 UTC 2017, Daniel Micay wrote:
>> 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).
> On Wed Jul 5 19:04:51 UTC 2017 , Daniel Micay wrote:
>> 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. -fno-plt code is fully compatible
>> with non -fno-plt code, the only requirement is that -fno-plt code is linked
>> with -Wl,-z,now which works fine for non -fno-plt code too and is desirable
>> for security either way.

The ongoing rebuild isn't about getting full RELRO, but recompiling
static libraries with PIE enabled. Another one that aims at removing
hardening-wrapper from repositories requires more attention to upstream
projects ignoring our compilation flags.

The plan is to modify binutils to enable BIND_NOW (for which Daniel
already provided me a patch), but it also requires some changes to make
test suite happy, so most likely I will work on it next Friday.

> I see [1]  -fstack-check is dropped and -fstack-protector-strong kept while being redundant. Anyone know what happened?
Current -fstack-check implementation is flawed[1] and after discussion
with Allan and Daniel, we have decided not to include it now. As even
now it would require entire repository to be rebuild, I don't see a
reason to do it now. I will get back to it when it's fixed.

[1] http://www.openwall.com/lists/oss-security/2017/06/19/9


More information about the arch-general mailing list