follow up the latest stack-protector-strong changes in libc too

[op]

Summary

for more info, see https://reviews.freebsd.org/D3463

(Obtained from HardenedBSD)

[jlh]

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".

[jlh]

Oliver,

Do you plan to make the test compile?

[op]

Sure, I plan to find time for check them. Thanks for the reminder.

[jlh]

Any update?

[pfg]

In D3848#238514, @jlh wrote:

Any update?

I just rebuilt my box with the change and it's still running but more testing is needed.

[jlh]

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.

[pfg]

In D3848#242083, @jlh wrote:

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.

[lattera-gmail.com]

In D3848#242229, @pfg wrote:

In D3848#242083, @jlh wrote:

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.

Would you like me to do a ports exp-run with this patch applied next week with HardenedBSD's infrastructure? I'd be more than happy to.

[pfg]

In D3848#242231, @lattera-gmail.com wrote:

In D3848#242229, @pfg wrote:

In D3848#242083, @jlh wrote:

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.

Would you like me to do a ports exp-run with this patch applied next week with HardenedBSD's infrastructure? I'd be more than happy to.

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.

[kib]

In D3848#242245, @pfg wrote:

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.

[pfg]

In D3848#242303, @kib wrote:

...

pfg, do not waste your time on this.

Thanks! I really have no time for this.