[PATCH] D101327: [Clang][Driver] validate sysregs for -mstack-protector-guard-reg=
David Spickett via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Apr 27 02:13:09 PDT 2021
DavidSpickett added a comment.
A lot of these system registers are going to be unsuitable for the stack canary. They're either read only, they have fixed bits, or they'll get overwritten by various system events.
I'm not suggesting we audit this list for those things, what seems reasonable to me is just to support the ones that the Linux kernel uses. (what GCC allows I'm not sure)
https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/AArch64-Options.html
-mstack-protector-guard=guard
-mstack-protector-guard-reg=reg
-mstack-protector-guard-offset=offset
Generate stack protection code using canary at guard. Supported locations are ‘global’ for a global canary or ‘sysreg’ for a canary in an appropriate system register.
With the latter choice the options -mstack-protector-guard-reg=reg and -mstack-protector-guard-offset=offset furthermore specify which system register to use as base register for reading the canary, and from what offset from that base register. There is no default register or offset as this is entirely for use within the Linux kernel.
So if kernel builds are using a small subset of registers, just check for those. Otherwise we've got another duplicated list that we (Arm) will probably forget to update anyway when new registers are added.
Either way it's one more stick on the "why doesn't clang just use the backend info" fire, but it's smaller at least if we limit the registers. E.g.
error: invalid value 'foo' in 'mstack-protector-guard-reg=','for AArch64' valid values are sp_el1 sp_el2
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D101327/new/
https://reviews.llvm.org/D101327
More information about the cfe-commits
mailing list