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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 15 Nov 2021 19:04:09 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     linux-hardening@...r.kernel.org
Cc:     Ard Biesheuvel <ardb@...nel.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>,
        Kyrylo Tkachov <kyryo.tkachov@....com>, gcc-patches@....gnu.org
Subject: [PATCH v5 0/1] implement TLS register based stack canary for ARM

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 v4:
- add a couple of test cases
- incorporate feedback received from Qing and Kyrylo

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

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: Kyrylo Tkachov <kyryo.tkachov@....com>
Cc: gcc-patches@....gnu.org

Ard Biesheuvel (1):
  [ARM] Add support for TLS register based stack protector canary access

 gcc/config/arm/arm-opts.h                        |  6 ++
 gcc/config/arm/arm-protos.h                      |  2 +
 gcc/config/arm/arm.c                             | 55 +++++++++++++++
 gcc/config/arm/arm.md                            | 71 +++++++++++++++++++-
 gcc/config/arm/arm.opt                           | 22 ++++++
 gcc/doc/invoke.texi                              | 11 +++
 gcc/testsuite/gcc.target/arm/stack-protector-7.c | 10 +++
 gcc/testsuite/gcc.target/arm/stack-protector-8.c |  5 ++
 8 files changed, 180 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/stack-protector-7.c
 create mode 100644 gcc/testsuite/gcc.target/arm/stack-protector-8.c

-- 
2.30.2

Powered by blists - more mailing lists