[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