From: Kees Cook <keescook@chromium.org>
To: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Will Deacon <will.deacon@arm.com>,
Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>,
Amit Kachhap <Amit.Kachhap@arm.com>,
Dave Martin <Dave.Martin@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC v2 7/7] arm64: compile the kernel with ptrauth return address signing
Date: Wed, 29 May 2019 20:45:22 -0700 [thread overview]
Message-ID: <201905292041.5297BF8C2F@keescook> (raw)
In-Reply-To: <20190529190332.29753-8-kristina.martsenko@arm.com>
On Wed, May 29, 2019 at 08:03:32PM +0100, Kristina Martsenko wrote:
> Compile all non-leaf 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.
>
> 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.
>
> Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Minor nits below...
Reviewed-by: Kees Cook <keescook@chromium.org>
> ---
>
> Changes since RFC v1:
> - Fixed support for compilers without ptrauth
> - Added support for the new -mbranch-protection option
> - Switched from protecting all functions to only protecting non-leaf functions
> (for no good reason, I have not done e.g. gadget analysis)
> - Moved __no_ptrauth definition to this patch, depending on compiler support
> - Updated the Kconfig symbol description
> - Updated the commit message
>
> arch/arm64/Kconfig | 12 +++++++++++-
> arch/arm64/Makefile | 6 ++++++
> arch/arm64/include/asm/pointer_auth.h | 6 ++++++
> 3 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index f4c1e9b30129..3ce93d88fae1 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1295,11 +1295,15 @@ 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.
> +
> The feature is detected at runtime. If the feature is not present in
> hardware it will not be advertised to userspace nor will it be
> enabled.
> @@ -1308,6 +1312,12 @@ 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
> + def_bool $(cc-option,-mbranch-protection=pac-ret)
> +
> +config CC_HAS_SIGN_RETURN_ADDRESS
> + def_bool $(cc-option,-msign-return-address=non-leaf)
> +
I would add comments here for "GCC 9, Clang" and "GCC 7, 8"
respectively, just so it's quickly obvious what's to be expected when
reading this later. :)
> endmenu
>
> config ARM64_SVE
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index b025304bde46..1dfbe755b531 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -66,6 +66,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=non-leaf
> +pac-flags-$(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET) := -mbranch-protection=pac-ret
> +KBUILD_CFLAGS += $(pac-flags-y)
> +endif
> +
> ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
> KBUILD_CPPFLAGS += -mbig-endian
> CHECKFLAGS += -D__AARCH64EB__
> diff --git a/arch/arm64/include/asm/pointer_auth.h b/arch/arm64/include/asm/pointer_auth.h
> index 5491c34b4dc3..3a83c40ffd8a 100644
> --- a/arch/arm64/include/asm/pointer_auth.h
> +++ b/arch/arm64/include/asm/pointer_auth.h
> @@ -15,7 +15,13 @@
> * allows pointer authentication to be enabled/disabled within the function
> * (but leaves the function unprotected by pointer authentication).
> */
> +#if defined(CONFIG_CC_HAS_BRANCH_PROT_PAC_RET)
> +#define __no_ptrauth __attribute__((target("branch-protection=none")))
> +#elif defined(CONFIG_CC_HAS_SIGN_RETURN_ADDRESS)
> +#define __no_ptrauth __attribute__((target("sign-return-address=none")))
> +#else
> #define __no_ptrauth
> +#endif
Is arch/arm64/include/asm/pointer_auth.h going to be included always?
I suspect the correct place for this might end up being in
include/linux/compiler_types.h, but for now, only a few select places
need it, so this is probably fine as-is.
>
> /*
> * Each key is a 128-bit quantity which is split across a pair of 64-bit
> --
> 2.11.0
>
I'm excited to test this series! :)
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-05-30 3:45 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-29 19:03 [RFC v2 0/7] arm64: return address signing Kristina Martsenko
2019-05-29 19:03 ` [RFC v2 1/7] arm64: cpufeature: add pointer auth meta-capabilities Kristina Martsenko
2019-05-30 1:58 ` Kees Cook
2019-05-30 10:50 ` Suzuki K Poulose
2019-06-13 16:13 ` Suzuki K Poulose
2019-05-29 19:03 ` [RFC v2 2/7] arm64: install user ptrauth keys at kernel exit time Kristina Martsenko
2019-05-30 2:04 ` Kees Cook
2019-06-06 16:26 ` Catalin Marinas
2019-05-29 19:03 ` [RFC v2 3/7] arm64: cpufeature: handle conflicts based on capability Kristina Martsenko
2019-05-30 2:49 ` Kees Cook
2019-05-30 14:16 ` Suzuki K Poulose
2019-05-31 14:00 ` Kristina Martsenko
2019-05-31 15:08 ` Suzuki K Poulose
2019-05-29 19:03 ` [RFC v2 4/7] arm64: enable ptrauth earlier Kristina Martsenko
2019-05-30 3:11 ` Kees Cook
2019-06-13 15:41 ` Suzuki K Poulose
2019-05-29 19:03 ` [RFC v2 5/7] arm64: initialize and switch ptrauth kernel keys Kristina Martsenko
2019-05-30 3:34 ` Kees Cook
2019-05-30 16:26 ` Kristina Martsenko
2019-06-04 10:03 ` Dave Martin
2019-06-06 16:44 ` Catalin Marinas
2019-06-12 16:21 ` Kristina Martsenko
2019-06-13 10:44 ` Catalin Marinas
2019-05-29 19:03 ` [RFC v2 6/7] arm64: unwind: strip PAC from kernel addresses Kristina Martsenko
2019-05-30 3:36 ` Kees Cook
2019-05-29 19:03 ` [RFC v2 7/7] arm64: compile the kernel with ptrauth return address signing Kristina Martsenko
2019-05-30 3:45 ` Kees Cook [this message]
2019-05-30 3:09 ` [RFC v2 0/7] arm64: " Kees Cook
2019-05-30 7:25 ` Will Deacon
2019-05-30 8:39 ` Ard Biesheuvel
2019-05-30 9:11 ` Ramana Radhakrishnan
2019-05-30 9:12 ` Ramana Radhakrishnan
2019-06-06 17:44 ` Kristina Martsenko
2019-06-08 4:09 ` Kees Cook
[not found] ` <DB7PR08MB3865C4AA36C9C465B2A687DABF180@DB7PR08MB3865.eurprd08.prod.outlook.com>
2019-05-30 15:57 ` Kees Cook
[not found] ` <DB7PR08MB3865A83066179CE419D171EDBF180@DB7PR08MB3865.eurprd08.prod.outlook.com>
2019-05-30 18:05 ` Kees Cook
2019-05-31 9:22 ` Will Deacon
2019-06-02 15:43 ` Kees Cook
2019-06-03 10:40 ` Will Deacon
2019-06-04 13:52 ` Luke Cheeseman
2019-06-06 17:43 ` Kristina Martsenko
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=201905292041.5297BF8C2F@keescook \
--to=keescook@chromium.org \
--cc=Amit.Kachhap@arm.com \
--cc=Dave.Martin@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--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).