linux-hardening - Re: [PATCH v4 0/1] implement TLS register based stack canary for ARM

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <CAMj1kXEVBg7uvYhoeav6KDKb45b4fMeCB3SQmYkJtUPyCRSDRg@mail.gmail.com>
Date:   Tue, 9 Nov 2021 19:12:38 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     linux-hardening@...r.kernel.org
Cc:     Kees Cook <keescook@...omium.org>,
        Keith Packard <keithpac@...zon.com>,
        thomas.preudhomme@...est.fr, adhemerval.zanella@...aro.org,
        Qing Zhao <qing.zhao@...cle.com>,
        Richard Sandiford <richard.sandiford@....com>,
        gcc-patches@....gnu.org
Subject: Re: [PATCH v4 0/1] implement TLS register based stack canary for ARM

On Thu, 28 Oct 2021 at 13:27, Ard Biesheuvel <ardb@...nel.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 <keithpac@...zon.com>
> Cc: thomas.preudhomme@...est.fr
> Cc: adhemerval.zanella@...aro.org
> Cc: Qing Zhao <qing.zhao@...cle.com>
> Cc: Richard Sandiford <richard.sandiford@....com>
> Cc: gcc-patches@....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.