On Thu, 28 Oct 2021 at 13:27, Ard Biesheuvel <a...@kernel.org> wrote: > > Bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102352 > > In the Linux kernel, user processes calling into the kernel are > essentially threads running in the same address space, of a program that > never terminates. This means that using a global variable for the stack > protector canary value is problematic on SMP systems, as we can never > change it unless we reboot the system. (Processes that sleep for any > reason will do so on a call into the kernel, which means that there will > always be live kernel stack frames carrying copies of the canary taken > when the function was entered) > > AArch64 implements -mstack-protector-guard=sysreg for this purpose, as > this permits the kernel to use different memory addresses for the stack > canary for each CPU, and context switch the chosen system register with > the rest of the process, allowing each process to use its own unique > value for the stack canary. > > This patch implements something similar, but for the 32-bit ARM kernel, > which will start using the user space TLS register TPIDRURO to index > per-process metadata while running in the kernel. This means we can just > add an offset to TPIDRURO to obtain the address from which to load the > canary value. > > Changes since v3: > - force a reload of the TLS register before performing the stack > protector check, so that we never rely on the stack for the address of > the canary > Changes since v2: > - fix the template for stack_protect_test_tls so it correctly conveys > the fact that it sets the Z flag > > Comments/suggestions welcome. > > Cc: Keith Packard <keith...@amazon.com> > Cc: thomas.preudho...@celest.fr > Cc: adhemerval.zane...@linaro.org > Cc: Qing Zhao <qing.z...@oracle.com> > Cc: Richard Sandiford <richard.sandif...@arm.com> > Cc: gcc-patches@gcc.gnu.org >
Note to reviewers: this feature has been accepted in LLVM/Clang, and so the exact command line options introduced by this patch to enable this feature can no longer be changed easily. I don't expect this to be an issue, given that they are the same as x86, but I thought I should note it nonetheless.
