lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 9 Nov 2021 19:12:38 +0100
From:   Ard Biesheuvel <>
Cc:     Kees Cook <>,
        Keith Packard <>,,,
        Qing Zhao <>,
        Richard Sandiford <>,
Subject: Re: [PATCH v4 0/1] implement TLS register based stack canary for ARM

On Thu, 28 Oct 2021 at 13:27, Ard Biesheuvel <> wrote:
> Bugzilla:
> 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 <>
> Cc:
> Cc:
> Cc: Qing Zhao <>
> Cc: Richard Sandiford <>
> Cc:

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.

Powered by blists - more mailing lists