From: Ard Biesheuvel <ardb@kernel.org>
To: linux-arm-kernel@lists.infradead.org
Cc: Ard Biesheuvel <ardb@kernel.org>, Marc Zyngier <maz@kernel.org>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Kees Cook <keescook@chromium.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Brown <broonie@kernel.org>
Subject: [PATCH v3 0/4] arm64: Add return address protection to asm code
Date: Fri, 9 Dec 2022 16:20:44 +0100 [thread overview]
Message-ID: <20221209152048.3517080-1-ardb@kernel.org> (raw)
Control flow integrity features such as shadow call stack or PAC work by
placing special instructions between the reload of the link register
from the stack and the function return. The point of this is not only to
protect the control flow when calling that particular function, but also
to ensure that the sequence of instructions appearing at the end of the
function cannot be subverted and used in other ways than intended, in a
ROP/JOP style attack.
This means that it is generally a bad idea to incorporate any code that
is rarely or never used, but lacks such protections. So add some macros
that we can invoke in assembler code to protect the return address while
it is stored on the stack, and wire it up in the ftrace code, which is
often built into production kernels even when not used.
Another example of this is crypto code, and some fixes have been queued
up in the cryptodev tree to ensure that the frame_push and frame_pop
macros are used consistently.
v3:
- rebase onto updated ftrace tree
- drop EFI changes for the time being, I'll bring those back later
- emit unwind directives for return address registers != x30, and handle
them in the dynamic SCS patching code
Cc: Marc Zyngier <maz@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Ard Biesheuvel (4):
arm64: assembler: Force error on misuse of .Lframe_local_offset
arm64: assembler: Protect return addresses in asm routines
arm64: ftrace: Preserve original link register value in ftrace_regs
arm64: ftrace: Add return address protection
arch/arm64/include/asm/assembler.h | 76 ++++++++++++++++++++
arch/arm64/include/asm/ftrace.h | 2 +-
arch/arm64/kernel/entry-ftrace.S | 27 +++++--
arch/arm64/kernel/patch-scs.c | 70 +++++++++++++-----
arch/arm64/kernel/stacktrace.c | 1 +
5 files changed, 151 insertions(+), 25 deletions(-)
--
2.35.1
_______________________________________________
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-12-09 15:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 15:20 Ard Biesheuvel [this message]
2022-12-09 15:20 ` [PATCH v3 1/4] arm64: assembler: Force error on misuse of .Lframe_local_offset Ard Biesheuvel
2022-12-09 15:20 ` [PATCH v3 2/4] arm64: assembler: Protect return addresses in asm routines Ard Biesheuvel
2022-12-09 15:20 ` [PATCH v3 3/4] arm64: ftrace: Preserve original link register value in ftrace_regs Ard Biesheuvel
2022-12-09 15:20 ` [PATCH v3 4/4] arm64: ftrace: Add return address protection 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=20221209152048.3517080-1-ardb@kernel.org \
--to=ardb@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--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).