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
