Skip to content

Commit 8cb37a5

Browse files
melverkees
authored andcommitted
stack: Introduce CONFIG_RANDOMIZE_KSTACK_OFFSET
The randomize_kstack_offset feature is unconditionally compiled in when the architecture supports it. To add constraints on compiler versions, we require a dedicated Kconfig variable. Therefore, introduce RANDOMIZE_KSTACK_OFFSET. Furthermore, this option is now also configurable by EXPERT kernels: while the feature is supposed to have zero performance overhead when disabled, due to its use of static branches, there are few cases where giving a distribution the option to disable the feature entirely makes sense. For example, in very resource constrained environments, which would never enable the feature to begin with, in which case the additional kernel code size increase would be redundant. Signed-off-by: Marco Elver <elver@google.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20220131090521.1947110-1-elver@google.com
1 parent ae97800 commit 8cb37a5

3 files changed

Lines changed: 24 additions & 6 deletions

File tree

arch/Kconfig

Lines changed: 18 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1159,16 +1159,29 @@ config HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET
11591159
to the compiler, so it will attempt to add canary checks regardless
11601160
of the static branch state.
11611161

1162-
config RANDOMIZE_KSTACK_OFFSET_DEFAULT
1163-
bool "Randomize kernel stack offset on syscall entry"
1162+
config RANDOMIZE_KSTACK_OFFSET
1163+
bool "Support for randomizing kernel stack offset on syscall entry" if EXPERT
1164+
default y
11641165
depends on HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET
11651166
help
11661167
The kernel stack offset can be randomized (after pt_regs) by
11671168
roughly 5 bits of entropy, frustrating memory corruption
11681169
attacks that depend on stack address determinism or
1169-
cross-syscall address exposures. This feature is controlled
1170-
by kernel boot param "randomize_kstack_offset=on/off", and this
1171-
config chooses the default boot state.
1170+
cross-syscall address exposures.
1171+
1172+
The feature is controlled via the "randomize_kstack_offset=on/off"
1173+
kernel boot param, and if turned off has zero overhead due to its use
1174+
of static branches (see JUMP_LABEL).
1175+
1176+
If unsure, say Y.
1177+
1178+
config RANDOMIZE_KSTACK_OFFSET_DEFAULT
1179+
bool "Default state of kernel stack offset randomization"
1180+
depends on RANDOMIZE_KSTACK_OFFSET
1181+
help
1182+
Kernel stack offset randomization is controlled by kernel boot param
1183+
"randomize_kstack_offset=on/off", and this config chooses the default
1184+
boot state.
11721185

11731186
config ARCH_OPTIONAL_KERNEL_RWX
11741187
def_bool n

include/linux/randomize_kstack.h

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,7 @@
22
#ifndef _LINUX_RANDOMIZE_KSTACK_H
33
#define _LINUX_RANDOMIZE_KSTACK_H
44

5+
#ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET
56
#include <linux/kernel.h>
67
#include <linux/jump_label.h>
78
#include <linux/percpu-defs.h>
@@ -50,5 +51,9 @@ void *__builtin_alloca(size_t size);
5051
raw_cpu_write(kstack_offset, offset); \
5152
} \
5253
} while (0)
54+
#else /* CONFIG_RANDOMIZE_KSTACK_OFFSET */
55+
#define add_random_kstack_offset() do { } while (0)
56+
#define choose_random_kstack_offset(rand) do { } while (0)
57+
#endif /* CONFIG_RANDOMIZE_KSTACK_OFFSET */
5358

5459
#endif

init/main.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -853,7 +853,7 @@ static void __init mm_init(void)
853853
pti_init();
854854
}
855855

856-
#ifdef CONFIG_HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET
856+
#ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET
857857
DEFINE_STATIC_KEY_MAYBE_RO(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT,
858858
randomize_kstack_offset);
859859
DEFINE_PER_CPU(u32, kstack_offset);

0 commit comments

Comments
 (0)