linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Amit Daniel Kachhap <amit.kachhap@arm.com>
To: linux-arm-kernel@lists.infradead.org
Cc: Mark Rutland <mark.rutland@arm.com>,
	Kees Cook <keescook@chromium.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Will Deacon <will.deacon@arm.com>,
	Kristina Martsenko <kristina.martsenko@arm.com>,
	James Morse <james.morse@arm.com>,
	Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>,
	Amit Daniel Kachhap <amit.kachhap@arm.com>,
	Vincenzo Frascino <Vincenzo.Frascino@arm.com>,
	Dave Martin <Dave.Martin@arm.com>
Subject: [PATCH 11/11] arm64: compile the kernel with ptrauth return address signing
Date: Thu, 17 Oct 2019 13:44:25 +0530	[thread overview]
Message-ID: <1571300065-10236-12-git-send-email-amit.kachhap@arm.com> (raw)
In-Reply-To: <1571300065-10236-1-git-send-email-amit.kachhap@arm.com>

From: Kristina Martsenko <kristina.martsenko@arm.com>

Compile all functions with two ptrauth instructions: PACIASP in the
prologue to sign the return address, and AUTIASP in the epilogue to
authenticate the return address (from the stack). If authentication
fails, the return will cause an instruction abort to be taken, followed
by an oops and killing the task.

This should help protect the kernel against attacks using
return-oriented programming. As ptrauth protects the return address, it
can also serve as a replacement for CONFIG_STACKPROTECTOR, although note
that it does not protect other parts of the stack.

The new instructions are in the HINT encoding space, so on a system
without ptrauth they execute as NOPs.

CONFIG_ARM64_PTR_AUTH now not only enables ptrauth for userspace and KVM
guests, but also automatically builds the kernel with ptrauth
instructions if the compiler supports it. If there is no compiler
support, we do not warn that the kernel was built without ptrauth
instructions.

GCC 7 and 8 support the -msign-return-address option, while GCC 9
deprecates that option and replaces it with -mbranch-protection. Support
both options.

Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
---
Changes since RFC v2:
 - Removed function attribute definition [Suzuki]
 - Added comments about GCC versions to Kconfig symbols [Kees]
 - Added a note in Kconfig (and the commit message) about STACKPROTECTOR
 - Changed GCC option to protect all functions with ptrauth and just non-leaf.

 arch/arm64/Kconfig  | 16 +++++++++++++++-
 arch/arm64/Makefile |  6 ++++++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8e86f6a..f83db93 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1399,11 +1399,17 @@ config ARM64_PTR_AUTH
 	  and other attacks.
 
 	  This option enables these instructions at EL0 (i.e. for userspace).
-
 	  Choosing this option will cause the kernel to initialise secret keys
 	  for each process at exec() time, with these keys being
 	  context-switched along with the process.
 
+	  If the compiler supports the -mbranch-protection or
+	  -msign-return-address flag (e.g. GCC 7 or later), then this option
+	  will also cause the kernel itself to be compiled with return address
+	  protection. In this case, and if the target hardware is known to
+	  support pointer authentication, then CONFIG_STACKPROTECTOR can be
+	  disabled with minimal loss of protection.
+
 	  The feature is detected at runtime. If the feature is not present in
 	  hardware it will not be advertised to userspace/KVM guest nor will it
 	  be enabled. However, KVM guest also require VHE mode and hence
@@ -1413,6 +1419,14 @@ config ARM64_PTR_AUTH
 	  then the secondary CPU will be offlined. On such a system, this
 	  option should not be selected.
 
+config CC_HAS_BRANCH_PROT_PAC_RET
+	# GCC 9 or later
+	def_bool $(cc-option,-mbranch-protection=pac-ret+leaf)
+
+config CC_HAS_SIGN_RETURN_ADDRESS
+	# GCC 7, 8
+	def_bool $(cc-option,-msign-return-address=all)
+
 endmenu
 
 config ARM64_SVE
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 84a3d50..4dbe86a 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -88,6 +88,12 @@ stack_protector_prepare: prepare0
 					include/generated/asm-offsets.h))
 endif
 
+ifeq ($(CONFIG_ARM64_PTR_AUTH),y)
+pac-flags-$(CONFIG_CC_HAS_SIGN_RETURN_ADDRESS) := -msign-return-address=all
+pac-flags-$(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET) := -mbranch-protection=pac-ret+leaf
+KBUILD_CFLAGS += $(pac-flags-y)
+endif
+
 ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
 KBUILD_CPPFLAGS	+= -mbig-endian
 CHECKFLAGS	+= -D__AARCH64EB__
-- 
2.7.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-10-17  8:18 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-17  8:14 [PATCH 00/11] arm64: return address signing Amit Daniel Kachhap
2019-10-17  8:14 ` [PATCH 01/11] arm64: cpufeature: add pointer auth meta-capabilities Amit Daniel Kachhap
2019-10-17  8:14 ` [PATCH 02/11] arm64: install user ptrauth keys at kernel exit time Amit Daniel Kachhap
2019-10-17  8:14 ` [PATCH 03/11] arm64: cpufeature: handle conflicts based on capability Amit Daniel Kachhap
2019-10-17 14:06   ` Suzuki K Poulose
2019-10-18  9:59     ` Amit Kachhap
2019-10-17  8:14 ` [PATCH 04/11] arm64: create macro to park cpu in an infinite loop Amit Daniel Kachhap
2019-10-17  8:14 ` [PATCH 05/11] arm64: enable ptrauth earlier Amit Daniel Kachhap
2019-10-17 14:13   ` Suzuki K Poulose
2019-10-18 10:07     ` Amit Kachhap
2019-10-23 17:32   ` James Morse
2019-10-30  4:01     ` Amit Daniel Kachhap
2019-10-17  8:14 ` [PATCH 06/11] arm64: rename ptrauth key structures to be user-specific Amit Daniel Kachhap
2019-10-29 23:27   ` Kees Cook
2019-10-17  8:14 ` [PATCH 07/11] arm64: initialize and switch ptrauth kernel keys Amit Daniel Kachhap
2019-10-23 17:35   ` James Morse
2019-10-30  4:02     ` Amit Daniel Kachhap
2019-10-17  8:14 ` [PATCH 08/11] arm64: unwind: strip PAC from kernel addresses Amit Daniel Kachhap
2019-10-23 17:36   ` James Morse
2019-10-30  4:02     ` Amit Daniel Kachhap
2019-10-17  8:14 ` [RFC PATCH 09/11] arm64: suspend: restore the kernel ptrauth keys Amit Daniel Kachhap
2019-10-17  8:14 ` [RFC PATCH 10/11] arm64: mask PAC bits of __builtin_return_address Amit Daniel Kachhap
2019-10-17  8:14 ` Amit Daniel Kachhap [this message]
2019-10-23 17:31 ` [PATCH 00/11] arm64: return address signing James Morse
2019-10-30  3:59   ` Amit Daniel Kachhap

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=1571300065-10236-12-git-send-email-amit.kachhap@arm.com \
    --to=amit.kachhap@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=Vincenzo.Frascino@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=keescook@chromium.org \
    --cc=kristina.martsenko@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=ramana.radhakrishnan@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will.deacon@arm.com \
    /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).