https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78875
Bug ID: 78875
Summary: -fstack-protector on powerpc64 now always use TLS,
won't work for kernel/firmware
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: benh at kernel dot crashing.org
Target Milestone: ---
Some standalone (not linked with glibc) programs such as the Linux Kernel
or the OPAL firmware do not have a TLS per-se. They use r13 for different
purposes (both examples here use it as some kind of per-cpu pointer).
Depending on gcc version and how it was built, the canary used by
-fstack-protector on powerpc64 is either loaded from a global (r2 relative) or
from the TLS (r13).
The latter case won't work for those programs. I looked into doing like x86 and
basically maintaining an equivalent of that portion of the TLS space for this,
but the offset used -0x7000 really doesn't work with either Linux or OPAL
without major changes to how they use r13.
In the meantime, it would be useful to still be able to exploit the stack
protector, to be able to force via a gcc command line option, the use of
globals instead of TLS (and in general disable any built-in access to the TLS
for projects that have a special runtime environment that doesn't use r13 for
that purpose).
