Does ld.so need padded TLS?

[fw-immunant]

From Slack:

Ayrton: does ld.so need padded tls?

Frances: that's a very good question, I'll do some investigation tomorrow because I'm not sure off the top of my head; at least plausibly it does, if it persists in the address space and its TLS gets accessed from different compartments after startup... on the other hand if we frontload all dynamic loading the way we plan to, that might interact here

Ayrton: that would make sense. Also I noticed the nginx demo doesn't use padded libc. I don't think it's necessarily worth spending time to fix but I just wanted to clarify when it was necessary/what the memory layout of TLS is like since presumably nginx does rely on libc TLS via errno

[ayrtonm]

The same question also applies to libgcc_s.so.1 and libstdc++.so.6

[fw-immunant]

The good news is that on ARM the situation is a bit simpler, because when we compile everything with our toolchain we use libcxx instead of libstdc++, which means that libgcc_s.so is no longer involved (libcxx doesn't depend on it) and libc++.so blessedly has no static TLS, so it doesn't need to be padded.

On x86_64, the real question is when the TLS of these shared objects gets accessed.

[kkysen]

Is there any downside to padding all of these, though? I'm not sure exactly how to use a padded ld.so since it's the loader, but the others seem simple if you're already padding all of the other libraries.