From: Kees Cook <keescook@chromium.org>
To: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
"Diogo N. Sampaio" <diogo.sampaio@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Luke Cheeseman <luke.cheeseman@arm.com>,
Will Deacon <will.deacon@arm.com>,
Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>,
Amit Kachhap <Amit.Kachhap@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Dave Martin <Dave.Martin@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC v2 0/7] arm64: return address signing
Date: Wed, 29 May 2019 20:09:23 -0700 [thread overview]
Message-ID: <201905292004.3809FBAA66@keescook> (raw)
In-Reply-To: <20190529190332.29753-1-kristina.martsenko@arm.com>
On Wed, May 29, 2019 at 08:03:25PM +0100, Kristina Martsenko wrote:
> This series improves function return address protection for the arm64 kernel, by
> compiling the kernel with ARMv8.3 Pointer Authentication instructions. This
> should help protect the kernel against attacks using return-oriented
> programming.
Can you speak to whether this feature should be enalbed in addition to
or instead of the standard stack canary option?
> - The patches make use of the sign-return-address/branch-protection compiler
> options and function attributes. GCC supports both, but Clang/LLVM appears
> to only support the compiler option, not the function attribute, so with
> these patches (and CONFIG_ARM64_PTR_AUTH=y) an LLVM-built kernel will fail
> to boot on ARMv8.3 CPUs. I don't yet know why LLVM does not support it, or
> whether support can be added. This series may need to be rewritten to not
> use the attribute, and instead move the functionality to assembly, or to
> disable return address signing when building with LLVM.
I've added Luke Cheeseman and Diogo N. Sampaio to CC. In looking quickly
at the LLVM support for branch-protection, I think it's just missing the
attribute target glue needed to "notice" the attribute markings. Luke,
is this expected to work Clang currently? I'm not familiar yet with
how attributes get wired up, but I think it should be quite possible.
> - more testing
Is PAC emulated in QEmu yet? (I assume I can't get real hardware to help
test this yet...)
--
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:09 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
2019-05-30 3:09 ` Kees Cook [this message]
2019-05-30 7:25 ` [RFC v2 0/7] arm64: " 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=201905292004.3809FBAA66@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=diogo.sampaio@arm.com \
--cc=kristina.martsenko@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=luke.cheeseman@arm.com \
--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