This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: --enable-stack-protector for glibc, v7


On 06/27/2016 05:27 PM, Nix wrote:
On 24 Jun 2016, Florian Weimer stated:

On 06/07/2016 01:06 PM, Nix wrote:
This is version 7 of the stack-protected glibc patch, incorporating all review
comments to date (unless I missed some).

I went through this patch series.

Taking stock, I think the only remaining problem is the order of IFUNC
resolvers and TCB initializers in the static linking case. The patch
series does IFUNCs first, then TCBs. I think we should keep the
existing order, TCB first, then IFUNCs. It seems the more conservative
choice, but I do not have much experience with static linking.

I didn't either before, I did this work. You get much more experienced
with it when it is your primary source of mysterious crashes for ages :)


As far as I can see, the order has not changed. We used to do:

So it's the same thing, only more explicit.

Right, thanks for explaining this to me.

(It might also help to avoid dropping stack protection from IFUNCs,
but since IFUNCs can do so little, that should not matter.)

I don't think we can avoid that.  In the dynamic-linking case, the
canary is initialized a long, long time after ifunc resolvers get
applied and ifuncs start getting called, and I don't want to start
messing with ld.so in this patch series :)

But this affects not just IFUNC resolvers in glibc, but also external IFUNC resolvers in static libraries. They might have been compiled with -fstack-protector-all, and require a TCB.

The issue here is not that the stack guard has not been initialized, it's that the TCB address has not been set. And as a result of that, any TLS is just invalid. This would also affect error reporting through errno.

If we can land Stefan Liebler's IFUNC cleanup, then disabling stack-protector for IFUNC resolvers will be a very simple patch. So we could start with that approach, and revisit this topic later. As you pointed out, we are not changing the IFUNC resolver calling order with regards to TCB setup, so lack of support for stack-protected IFUNC resolvers is not a regression.

Thanks,
Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]