The arm64 Guarded Control Stack (GCS) feature provides support for
hardware protected stacks of return addresses, intended to provide
hardening against return oriented programming (ROP) attacks and to make
it easier to gather call stacks for applications such as profiling.
When GCS is active a sec
Currently arch_validate_flags() is written in a very non-extensible
fashion, returning immediately if MTE is not supported and writing the MTE
check as a direct return. Since we will want to add more checks for GCS
refactor the existing code to be more extensible, no functional change
intended.
Si
Three architectures (x86, aarch64, riscv) have announced support for
shadow stacks with fairly similar functionality. While x86 is using
arch_prctl() to control the functionality neither arm64 nor riscv uses
that interface so this patch adds arch-agnostic prctl() support to
get and set status of s
In preparation for adding arm64 GCS support make the map_shadow_stack()
SHADOW_STACK_SET_TOKEN flag generic and add _SET_MARKER. The existing
flag indicats that a token usable for stack switch should be added to
the top of the newly mapped GCS region while the new flag indicates that
a top of stack
FEAT_GCS introduces a number of new system registers, we require that
access to these registers is not trapped when we identify that the feature
is detected.
Signed-off-by: Mark Brown
---
Documentation/arch/arm64/booting.rst | 22 ++
1 file changed, 22 insertions(+)
diff --g
Add some documentation of the userspace ABI for Guarded Control Stacks.
Signed-off-by: Mark Brown
---
Documentation/arch/arm64/gcs.rst | 233 +
Documentation/arch/arm64/index.rst | 1 +
2 files changed, 234 insertions(+)
diff --git a/Documentation/arch/ar
The architecture defines a format for guarded control stack caps, used
to mark the top of an unused GCS in order to limit the potential for
exploitation via stack switching. Add definitions associated with these.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/sysreg.h | 20
Define C callable functions for GCS instructions used by the kernel. In
order to avoid ambitious toolchain requirements for GCS support these are
manually encoded, this means we have fixed register numbers which will be
a bit limiting for the compiler but none of these should be used in
sufficientl
In order for EL1 to write to an EL0 GCS it must use the GCSSTTR instruction
rather than a normal STTR. Provide a put_user_gcs() which does this.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/uaccess.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/inclu
Add a cpufeature for GCS, allowing other code to conditionally support it
at runtime.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/cpufeature.h | 6 ++
arch/arm64/kernel/cpufeature.c | 16
arch/arm64/tools/cpucaps| 1 +
3 files changed, 23 insertio
Pages used for guarded control stacks need to be described to the hardware
using the Permission Indirection Extension, GCS is not supported without
PIE. In order to support copy on write for guarded stacks we allocate two
values, one for active GCSs and one for GCS pages marked as read only prior
t
Use VM_HIGH_ARCH_5 for guarded control stack pages.
Signed-off-by: Mark Brown
---
Documentation/filesystems/proc.rst | 2 +-
fs/proc/task_mmu.c | 3 +++
include/linux/mm.h | 12 +++-
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documen
Map pages flagged as being part of a GCS as such rather than using the
full set of generic VM flags.
This is done using a conditional rather than extending the size of
protection_map since that would make for a very sparse array.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/mman.h | 9
GCS introduces a number of system registers for EL1 and EL0, on systems
with GCS we need to context switch them and expose them to VMMs to allow
guests to use GCS, as well as describe their fine grained traps to
nested virtualisation. Traps are already disabled.
Signed-off-by: Mark Brown
---
ar
There is a control HCRX_EL2.GCSEn which must be set to allow GCS
features to take effect at lower ELs and also fine grained traps for GCS
usage at EL0 and EL1. Configure all these to allow GCS usage by EL0 and
EL1.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/el2_setup.h | 17 ++
Hook up an override for GCS, allowing it to be disabled from the command
line by specifying arm64.nogcs in case there are problems.
Signed-off-by: Mark Brown
---
Documentation/admin-guide/kernel-parameters.txt | 6 ++
arch/arm64/kernel/idreg-override.c | 2 ++
2 files changed, 8
Provide a hwcap to enable userspace to detect support for GCS.
Signed-off-by: Mark Brown
---
Documentation/arch/arm64/elf_hwcaps.rst | 3 +++
arch/arm64/include/asm/hwcap.h | 1 +
arch/arm64/include/uapi/asm/hwcap.h | 1 +
arch/arm64/kernel/cpufeature.c | 3 +++
arch/arm64/
A new exception code is defined for GCS specific faults other than
standard load/store faults, for example GCS token validation failures,
add handling for this. These faults are reported to userspace as
segfaults with code SEGV_CPERR (protection error), mirroring the
reporting for x86 shadow stack
All GCS operations at EL0 must happen on a page which is marked as
having UnprivGCS access, including read operations. If a GCS operation
attempts to access a page without this then it will generate a data
abort with the GCS bit set in ESR_EL1.ISS2.
EL0 may validly generate such faults, for examp
There are two registers controlling the GCS state of EL0, GCSPR_EL0 which
is the current GCS pointer and GCSCRE0_EL1 which has enable bits for the
specific GCS functionality enabled for EL0. Manage these on context switch
and process lifetime events, GCS is reset on exec(). Also ensure that
any ch
When a new thread is created by a thread with GCS enabled the GCS needs
to be specified along with the regular stack. clone3() has been
extended to support this case, allowing userspace to explicitly specify
the size and location of the GCS. The specified GCS must have a valid
GCS token at the to
Implement the architecture neutral prtctl() interface for setting the
shadow stack status, this supports setting and reading the current GCS
configuration for the current thread.
Userspace can enable basic GCS functionality and additionally also
support for GCS pushes and arbitrary GCS stores. It
As discussed extensively in the changelog for the addition of this
syscall on x86 ("x86/shstk: Introduce map_shadow_stack syscall") the
existing mmap() and madvise() syscalls do not map entirely well onto the
security requirements for guarded control stacks since they lead to
windows where memory i
When invoking a signal handler we use the GCS configuration and stack
for the current thread.
Since we implement signal return by calling the signal handler with a
return address set up pointing to a trampoline in the vDSO we need to
also configure any active GCS for this by pushing a frame for th
Add a context for the GCS state and include it in the signal context when
running on a system that supports GCS. We reuse the same flags that the
prctl() uses to specify which GCS features are enabled and also provide the
current GCS pointer.
We do not support enabling GCS via signal return, there
Provide a new register type NT_ARM_GCS reporting the current GCS mode
and pointer for EL0. Due to the interactions with allocation and
deallocation of Guarded Control Stacks we do not permit any changes to
the GCS mode via ptrace, only GCSPR_EL0 may be changed.
Signed-off-by: Mark Brown
---
arc
Provide a Kconfig option allowing the user to select if GCS support is
built into the kernel.
Signed-off-by: Mark Brown
---
arch/arm64/Kconfig | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index aa7c1d435139..e0048e4660cf 100644
Add coverage of the GCS hwcap to the hwcap selftest, using a read of
GCSPR_EL0 to generate SIGILL without having to worry about enabling GCS.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/abi/hwcap.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/tools/tes
In preparation for testing GCS related signal handling add it as a feature
we check for in the signal handling support code.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/signal/test_signals.h | 2 ++
tools/testing/selftests/arm64/signal/test_signals_utils.c | 3 +++
2 files
Teach the framework about the GCS signal context, avoiding warnings on
the unknown context.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/signal/testcases/testcases.c | 7 +++
tools/testing/selftests/arm64/signal/testcases/testcases.h | 1 +
2 files changed, 8 insertions(+)
di
Currently we ignore si_code unless the expected signal is a SIGSEGV, in
which case we enforce it being SEGV_ACCERR. Allow test cases to specify
exactly which si_code should be generated so we can validate this, and
test for other segfault codes.
Signed-off-by: Mark Brown
---
.../testing/selftest
Since it is not possible to return from the function that enabled GCS
without disabling GCS it is very inconvenient to use the signal handling
tests to cover GCS when GCS is not enabled by the toolchain and runtime,
something that no current distribution does. Since none of the testcases
do anythin
This test program just covers the basic GCS ABI, covering aspects of the
ABI as standalone features without attempting to integrate things.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/Makefile| 2 +-
tools/testing/selftests/arm64/gcs/.gitignore | 1 +
tools/testing/s
There are things like threads which nolibc struggles with which we want
to add coverage for, and the ABI allows us to test most of these even if
libc itself does not understand GCS so add a test application built
using the system libc.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/
Verify that we can lock individual GCS mode bits, that other modes
aren't affected and as a side effect also that every combination of
modes can be enabled.
Normally the inability to reenable GCS after disabling it would be an
issue with testing but fortunately the kselftest_harness runs each test
Do some testing of the signal handling for GCS, checking that a GCS
frame has the expected information in it and that the expected signals
are delivered with invalid operations.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/signal/.gitignore| 1 +
.../selftests/arm64/signal/te
Add a stress test which runs one more process than we have CPUs spinning
through a very recursive function with frequent syscalls immediately prior
to return and signals being injected every 100ms. The goal is to flag up
any scheduling related issues, for example failure to ensure that barriers
are
While it's a bit off topic for them the floating point stress tests do give
us some coverage of context thrashing cases, and also of active signal
delivery separate to the relatively complicated framework in the actual
signals tests. Have the tests enable GCS on startup, ignoring failures so
they c
Allow test programs to use the shadow stack helpers on arm64.
Signed-off-by: Mark Brown
---
tools/testing/selftests/ksft_shstk.h | 37
1 file changed, 37 insertions(+)
diff --git a/tools/testing/selftests/ksft_shstk.h
b/tools/testing/selftests/ksft_shstk.h
On Fri, Feb 02, 2024 at 03:09:05PM -0800, Manu Bretelle wrote:
> On Sun, Jan 28, 2024 at 06:24:05PM -0700, Daniel Xu wrote:
> > === Description ===
> >
> > This is a bpf-treewide change that annotates all kfuncs as such inside
> > .BTF_ids. This annotation eventually allows us to automatically gen
On Sat, Feb 03, 2024 at 03:40:24PM +0100, Jiri Olsa wrote:
> On Fri, Feb 02, 2024 at 03:09:05PM -0800, Manu Bretelle wrote:
> > On Sun, Jan 28, 2024 at 06:24:05PM -0700, Daniel Xu wrote:
> > > === Description ===
> > >
> > > This is a bpf-treewide change that annotates all kfuncs as such inside
>
Hi,
On 2/2/24 16:04, Mark Brown wrote:
> There are a number of architectures with shadow stack features which we are
> presenting to userspace with as consistent an API as we can (though there
> are some architecture specifics). Especially given that there are some
> important considerations for u
42 matches
Mail list logo
