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