Date: Fri, 15 Nov 2019 15:37:06 +0000 From: Mark Rutland <mark.rutland@....com> To: Sami Tolvanen <samitolvanen@...gle.com> Cc: Will Deacon <will@...nel.org>, Catalin Marinas <catalin.marinas@....com>, Steven Rostedt <rostedt@...dmis.org>, Masami Hiramatsu <mhiramat@...nel.org>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, Dave Martin <Dave.Martin@....com>, Kees Cook <keescook@...omium.org>, Laura Abbott <labbott@...hat.com>, Marc Zyngier <maz@...nel.org>, Nick Desaulniers <ndesaulniers@...gle.com>, Jann Horn <jannh@...gle.com>, Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Masahiro Yamada <yamada.masahiro@...ionext.com>, clang-built-linux@...glegroups.com, kernel-hardening@...ts.openwall.com, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH v5 05/14] add support for Clang's Shadow Call Stack (SCS) On Tue, Nov 05, 2019 at 03:55:59PM -0800, Sami Tolvanen wrote: > This change adds generic support for Clang's Shadow Call Stack, > which uses a shadow stack to protect return addresses from being > overwritten by an attacker. Details are available here: > > https://clang.llvm.org/docs/ShadowCallStack.html > > Note that security guarantees in the kernel differ from the > ones documented for user space. The kernel must store addresses > of shadow stacks used by other tasks and interrupt handlers in > memory, which means an attacker capable reading and writing > arbitrary memory may be able to locate them and hijack control > flow by modifying shadow stacks that are not currently in use. > > Signed-off-by: Sami Tolvanen <samitolvanen@...gle.com> > Reviewed-by: Kees Cook <keescook@...omium.org> > Reviewed-by: Miguel Ojeda <miguel.ojeda.sandonis@...il.com> > --- > Makefile | 6 ++ > arch/Kconfig | 33 ++++++ > include/linux/compiler-clang.h | 6 ++ > include/linux/compiler_types.h | 4 + > include/linux/scs.h | 57 ++++++++++ > init/init_task.c | 8 ++ > kernel/Makefile | 1 + > kernel/fork.c | 9 ++ > kernel/sched/core.c | 2 + > kernel/scs.c | 187 +++++++++++++++++++++++++++++++++ > 10 files changed, 313 insertions(+) > create mode 100644 include/linux/scs.h > create mode 100644 kernel/scs.c > > diff --git a/Makefile b/Makefile > index b37d0e8fc61d..7f3a4c5c7dcc 100644 > --- a/Makefile > +++ b/Makefile > @@ -846,6 +846,12 @@ ifdef CONFIG_LIVEPATCH > KBUILD_CFLAGS += $(call cc-option, -flive-patching=inline-clone) > endif > > +ifdef CONFIG_SHADOW_CALL_STACK > +CC_FLAGS_SCS := -fsanitize=shadow-call-stack > +KBUILD_CFLAGS += $(CC_FLAGS_SCS) > +export CC_FLAGS_SCS > +endif > + > # arch Makefile may override CC so keep this after arch Makefile is included > NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include) > > diff --git a/arch/Kconfig b/arch/Kconfig > index 5f8a5d84dbbe..5e34cbcd8d6a 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -521,6 +521,39 @@ config STACKPROTECTOR_STRONG > about 20% of all kernel functions, which increases the kernel code > size by about 2%. > > +config ARCH_SUPPORTS_SHADOW_CALL_STACK > + bool > + help > + An architecture should select this if it supports Clang's Shadow > + Call Stack, has asm/scs.h, and implements runtime support for shadow > + stack switching. > + > +config SHADOW_CALL_STACK_VMAP > + bool > + depends on SHADOW_CALL_STACK > + help > + Use virtually mapped shadow call stacks. Selecting this option > + provides better stack exhaustion protection, but increases per-thread > + memory consumption as a full page is allocated for each shadow stack. The bool needs some display text to make it selectable. This should probably be below SHADOW_CALL_STACK so that when it shows up in menuconfig it's where you'd expect it to be. I locally hacked that in, but when building defconfig + SHADOW_CALL_STACK + SHADOW_CALL_STACK_VMAP, the build explodes as below: | [mark@...rids:~/src/linux]% usellvm 9.0.0 usekorg 8.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- CC=clang -j56 -s | arch/arm64/kernel/scs.c:28:7: error: use of undeclared identifier 'VMALLOC_START' | VMALLOC_START, VMALLOC_END, | ^ | arch/arm64/kernel/scs.c:28:22: error: use of undeclared identifier 'VMALLOC_END' | VMALLOC_START, VMALLOC_END, | ^ | arch/arm64/kernel/scs.c:29:7: error: use of undeclared identifier 'SCS_GFP' | SCS_GFP, PAGE_KERNEL, | ^ | arch/arm64/kernel/scs.c:29:16: error: use of undeclared identifier 'PAGE_KERNEL' | SCS_GFP, PAGE_KERNEL, | ^ | 4 errors generated. | scripts/Makefile.build:265: recipe for target 'arch/arm64/kernel/scs.o' failed | make: *** [arch/arm64/kernel/scs.o] Error 1 | scripts/Makefile.build:509: recipe for target 'arch/arm64/kernel' failed | make: *** [arch/arm64/kernel] Error 2 | Makefile:1655: recipe for target 'arch/arm64' failed | make: *** [arch/arm64] Error 2 | make: *** Waiting for unfinished jobs.... Other than that, this largely looks good to me! Thanks, Mark.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.