for more info, see https://reviews.freebsd.org/D3463
(Obtained from HardenedBSD)
op on Oct 8 2015, 8:51 PM.Authored by
This looks good to me, but I think this requires to compile libc once with -fstrack-protector-strong and check it works as expected. Possibly exercise it, like running unit test.
The easiest way to test this I think is to set SSP_CFLAGS to "-fstack-protector-all" so with your patch it should end up being "-fstack-protector-strong". Otherwise I think you can just comment this line and set SSP_CFLAGS manually to "-fstack-protector-strong".
I think stack protection has already been disabled in the very low level stuff. This change is fairly non-intrusive and I think he ready for further testing. Go ahead and commit please.
There are too many assumptions in the above statements. Oliver, have you tested this? I have only done very light testing so I don't want to assume responsibility.
Also, let me cc kib@ since this may end up affecting rtld.
Not really, thanks. Anything different than FreeBSD is likely to have many unknowns for us to consider conclusive. This also requires a different type of runtime testing.
At least on my desktop I am now seeing some strange behaviour that I hadn't seen before: XOrg not starting, unbound not resolving. it doesn't happen reproducibly and I don't know if it's related at all though.
Rtld entrance on lazy PLT entry resolution uses non-standard stack frame for obvious reasons. See arch/rtld_start.c:_rtld_bind_start. Functioning of this entry depends on many ABI details adhered to by the rtld C code. Without understanding what exact changes are caused by the instrumentation, no testing can prove that there is no latent issues.
pfg, do not waste your time on this.