From: Ard Biesheuvel <ardb@kernel.org>
To: linux-arm-kernel@lists.infradead.org
Cc: will@kernel.org, mark.rutland@arm.com, catalin.marinas@arm.com,
maz@kernel.org, Ard Biesheuvel <ardb@kernel.org>,
Kees Cook <keescook@google.com>,
Sami Tolvanen <samitolvanen@google.com>,
Fangrui Song <maskray@google.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Dan Li <ashimida@linux.alibaba.com>
Subject: [RFC PATCH v2 0/3] arm64: dynamic shadow call stack support
Date: Thu, 5 May 2022 18:10:08 +0200 [thread overview]
Message-ID: <20220505161011.1801596-1-ardb@kernel.org> (raw)
Generic kernel images such as Android's GKI typically enable all
security features, which are typically implemented in such a way that
they only take effect if the underlying hardware can support it, but
don't interfere with correct and efficient operation otherwise.
For shadow call stack support, which is always supported by the
hardware, it means it will be enabled even if pointer authentication is
also supported, and enabled for signing return addresses stored on the
stack. The additional security provided by shadow call stack is only
marginal in this case, whereas the performance overhead is not.
Given that return address signing is based on PACIASP/AUTIASP
instructions that implicitly operate on the return address register
(X30) and are not idempotent (i.e., each needs to be emitted exactly
once before the return address is stored on the ordinary stack and after
it has been retrieved from it), we can convert these instruction 1:1
into shadow call stack pushed and pops involving the register X30.
As this is something that can be done at runtime rather than build time,
we can do this conditionally based on whether or not return address
signing is supported on the underlying hardware.
In order to be able to unwind call stacks that involve return address
signing, whether or not the return address is currently signed is
tracked by DWARF CFI directives in the unwinding metadata. This means we
can use this information to locate all PACIASP/AUTIASP instructions in
the binary, instead of having to use brute force and go over all
instructions in the entire program.
This series implements this approach for Clang, which has recently been
fixed to emit all these CFI directives correctly. This series is based
on an older PoC sent out last year [0] that targeted GCC only (due to
this issue). This v2 targets Clang only, as GCC has its own issues with
CFI correctness.
Changes since RFC v1:
- implement boot time check for PAC/BTI support, and only enable dynamic
SCS if neither are supported;
- implement module patching as well;
- switch to Clang, and drop workaround for GCC bug;
[0] https://lore.kernel.org/linux-arm-kernel/20211013152243.2216899-1-ardb@kernel.org/
Cc: Kees Cook <keescook@google.com>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Fangrui Song <maskray@google.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Dan Li <ashimida@linux.alibaba.com>
Ard Biesheuvel (3):
arm64: unwind: add asynchronous unwind tables to kernel and modules
scs: add support for dynamic shadow call stacks
arm64: implement dynamic shadow call stack for Clang
Makefile | 2 +
arch/Kconfig | 7 +
arch/arm64/Kconfig | 11 +
arch/arm64/Makefile | 5 +
arch/arm64/include/asm/module.lds.h | 8 +
arch/arm64/include/asm/scs.h | 12 +
arch/arm64/kernel/Makefile | 2 +
arch/arm64/kernel/head.S | 3 +
arch/arm64/kernel/irq.c | 2 +-
arch/arm64/kernel/module.c | 10 +
arch/arm64/kernel/patch-scs.c | 257 ++++++++++++++++++++
arch/arm64/kernel/sdei.c | 2 +-
arch/arm64/kernel/setup.c | 5 +
arch/arm64/kernel/vmlinux.lds.S | 16 ++
drivers/firmware/efi/libstub/Makefile | 1 +
include/linux/scs.h | 10 +
kernel/scs.c | 14 +-
17 files changed, 363 insertions(+), 4 deletions(-)
create mode 100644 arch/arm64/kernel/patch-scs.c
--
2.30.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2022-05-05 16:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-05 16:10 Ard Biesheuvel [this message]
2022-05-05 16:10 ` [RFC PATCH v2 1/3] arm64: unwind: add asynchronous unwind tables to kernel and modules Ard Biesheuvel
2022-05-05 20:19 ` Nick Desaulniers
2022-05-06 7:07 ` Ard Biesheuvel
2022-05-05 16:10 ` [RFC PATCH v2 2/3] scs: add support for dynamic shadow call stacks Ard Biesheuvel
2022-05-05 21:14 ` Nick Desaulniers
2022-05-06 0:00 ` Kees Cook
2022-05-05 16:10 ` [RFC PATCH v2 3/3] arm64: implement dynamic shadow call stack for Clang Ard Biesheuvel
2022-05-05 21:01 ` Nick Desaulniers
2022-05-18 1:53 ` Sami Tolvanen
2022-05-06 0:00 ` Kees Cook
2022-05-06 6:59 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220505161011.1801596-1-ardb@kernel.org \
--to=ardb@kernel.org \
--cc=ashimida@linux.alibaba.com \
--cc=catalin.marinas@arm.com \
--cc=keescook@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=maskray@google.com \
--cc=maz@kernel.org \
--cc=ndesaulniers@google.com \
--cc=samitolvanen@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).