From: Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com> To: Will Deacon <Will.Deacon@arm.com>, Kristina Martsenko <Kristina.Martsenko@arm.com> Cc: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Adam Wallis <awallis@codeaurora.org>, Amit Kachhap <Amit.Kachhap@arm.com>, Andrew Jones <drjones@redhat.com>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Arnd Bergmann <arnd@arndb.de>, Catalin Marinas <Catalin.Marinas@arm.com>, Christoffer Dall <Christoffer.Dall@arm.com>, Dave P Martin <Dave.Martin@arm.com>, Jacob Bramley <Jacob.Bramley@arm.com>, Kees Cook <keescook@chromium.org>, Marc Zyngier <Marc.Zyngier@arm.com>, Mark Rutland <Mark.Rutland@arm.com>, Suzuki Poulose <Suzuki.Poulose@arm.com>, "kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>, "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.or> Subject: Re: [PATCH 00/17] ARMv8.3 pointer authentication support Date: Tue, 23 Oct 2018 08:39:19 +0000 [thread overview] Message-ID: <8478fc27-6e74-4fa6-7956-ffc1cca6c063@arm.com> (raw) In-Reply-To: <20181019123646.GG14246@arm.com> On 19/10/2018 13:36, Will Deacon wrote: > On Fri, Oct 05, 2018 at 09:47:37AM +0100, Kristina Martsenko wrote: >> 1) Key support >> >> This series enables the use of instructions using APIAKey, which is >> initialised and maintained per-process (shared by all threads). GCC >> currently only makes use of APIAKey. >> >> This series does not add support for APIBKey, APDAKey, APDBKey, nor >> APGAKey. HINT-space instructions using these keys will currently execute >> as NOPs. Support for these keys can be added as users appear. >> >> Note that while we expose the cpuid register (ID_AA64ISAR1_EL1) to >> userspace, it only contains one feature for address authentication >> (API/APA), so it cannot be used by userspace to tell which keys the >> kernel supports. For this the kernel exposes HWCAP bits, one per key >> (currently only APIAKey), which must be checked instead. > > Given that the architecture doesn't provide an identification mechanism > for the case where only one of the keys is available, I would much prefer > that we expose both of the keys to userspace. Is the only downside of > that a possible exception entry overhead if the kernel wants to use pointer > authentication as well? > > Having an initial implementation where the B key operations act as NOPs > isn't ideal if we want to support future users -- chances are they'll > be put off because deployed kernels don't give them whatever security > guarantees they require. It's a bit of a chicken-and-egg problem, so > unless we have good reasons to keep the B key hidden, I think we should > be exposing it from the start. There are patches in flight to get B key signing support in for GCC 9 - so exposing this to user space will be good. Ramana > > Will >
WARNING: multiple messages have this Message-ID (diff)
From: Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com> To: Will Deacon <Will.Deacon@arm.com>, Kristina Martsenko <Kristina.Martsenko@arm.com> Cc: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Adam Wallis <awallis@codeaurora.org>, Amit Kachhap <Amit.Kachhap@arm.com>, Andrew Jones <drjones@redhat.com>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Arnd Bergmann <arnd@arndb.de>, Catalin Marinas <Catalin.Marinas@arm.com>, Christoffer Dall <Christoffer.Dall@arm.com>, Dave P Martin <Dave.Martin@arm.com>, Jacob Bramley <Jacob.Bramley@arm.com>, Kees Cook <keescook@chromium.org>, Marc Zyngier <Marc.Zyngier@arm.com>, Mark Rutland <Mark.Rutland@arm.com>, Suzuki Poulose <Suzuki.Poulose@arm.com>, "kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>, "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>nd <nd@arm.com> Subject: Re: [PATCH 00/17] ARMv8.3 pointer authentication support Date: Tue, 23 Oct 2018 08:39:19 +0000 [thread overview] Message-ID: <8478fc27-6e74-4fa6-7956-ffc1cca6c063@arm.com> (raw) Message-ID: <20181023083919.U7kpzuufK4KNtHgcbrUQzkP9cpz7PtZC6L5GBfGat_o@z> (raw) In-Reply-To: <20181019123646.GG14246@arm.com> On 19/10/2018 13:36, Will Deacon wrote: > On Fri, Oct 05, 2018 at 09:47:37AM +0100, Kristina Martsenko wrote: >> 1) Key support >> >> This series enables the use of instructions using APIAKey, which is >> initialised and maintained per-process (shared by all threads). GCC >> currently only makes use of APIAKey. >> >> This series does not add support for APIBKey, APDAKey, APDBKey, nor >> APGAKey. HINT-space instructions using these keys will currently execute >> as NOPs. Support for these keys can be added as users appear. >> >> Note that while we expose the cpuid register (ID_AA64ISAR1_EL1) to >> userspace, it only contains one feature for address authentication >> (API/APA), so it cannot be used by userspace to tell which keys the >> kernel supports. For this the kernel exposes HWCAP bits, one per key >> (currently only APIAKey), which must be checked instead. > > Given that the architecture doesn't provide an identification mechanism > for the case where only one of the keys is available, I would much prefer > that we expose both of the keys to userspace. Is the only downside of > that a possible exception entry overhead if the kernel wants to use pointer > authentication as well? > > Having an initial implementation where the B key operations act as NOPs > isn't ideal if we want to support future users -- chances are they'll > be put off because deployed kernels don't give them whatever security > guarantees they require. It's a bit of a chicken-and-egg problem, so > unless we have good reasons to keep the B key hidden, I think we should > be exposing it from the start. There are patches in flight to get B key signing support in for GCC 9 - so exposing this to user space will be good. Ramana > > Will >
next prev parent reply other threads:[~2018-10-23 8:39 UTC|newest] Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-05 8:47 [PATCH 00/17] ARMv8.3 pointer authentication support Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-05 8:47 ` [PATCH v5 01/17] arm64: add pointer authentication register bits Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-11 16:28 ` Will Deacon 2018-10-11 16:28 ` Will Deacon 2018-10-12 8:53 ` Mark Rutland 2018-10-12 8:53 ` Mark Rutland 2018-10-12 8:56 ` Will Deacon 2018-10-12 8:56 ` Will Deacon 2018-10-12 9:50 ` Mark Rutland 2018-10-12 9:50 ` Mark Rutland 2018-10-05 8:47 ` [PATCH v5 02/17] arm64/kvm: consistently handle host HCR_EL2 flags Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-05 8:47 ` [PATCH v5 03/17] arm64/kvm: hide ptrauth from guests Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-05 8:47 ` [PATCH v5 04/17] arm64: Don't trap host pointer auth use to EL2 Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-05 8:47 ` [PATCH v5 05/17] arm64/cpufeature: detect pointer authentication Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-05 8:47 ` [PATCH v5 06/17] asm-generic: mm_hooks: allow hooks to be overridden individually Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-05 8:47 ` [PATCH v5 07/17] arm64: add basic pointer authentication support Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-11 16:00 ` Suzuki K Poulose 2018-10-11 16:00 ` Suzuki K Poulose 2018-10-19 11:15 ` Catalin Marinas 2018-10-19 11:15 ` Catalin Marinas 2018-10-19 11:24 ` Will Deacon 2018-10-19 11:24 ` Will Deacon 2018-10-19 15:36 ` Kees Cook 2018-10-19 15:36 ` Kees Cook 2018-10-19 15:49 ` Will Deacon 2018-10-19 15:49 ` Will Deacon 2018-10-19 16:05 ` Kees Cook 2018-10-19 16:05 ` Kees Cook 2018-10-19 16:16 ` Will Deacon 2018-10-19 16:16 ` Will Deacon 2018-10-19 15:54 ` Mark Rutland 2018-10-19 15:54 ` Mark Rutland 2018-10-19 16:49 ` Cyrill Gorcunov 2018-10-19 16:49 ` Cyrill Gorcunov 2018-11-14 18:11 ` Will Deacon 2018-11-14 18:11 ` Will Deacon 2018-11-15 10:25 ` Dave Martin 2018-11-15 10:25 ` Dave Martin 2018-10-23 8:36 ` Ramana Radhakrishnan 2018-10-23 8:36 ` Ramana Radhakrishnan 2018-10-23 10:20 ` Will Deacon 2018-10-23 10:20 ` Will Deacon 2018-10-05 8:47 ` [PATCH v5 08/17] arm64: expose user PAC bit positions via ptrace Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-05 8:47 ` [PATCH v5 09/17] arm64: perf: strip PAC when unwinding userspace Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-05 8:47 ` [PATCH v5 10/17] arm64: enable pointer authentication Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-05 8:47 ` [PATCH v5 11/17] arm64: docs: document " Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-05 9:04 ` Ramana Radhakrishnan 2018-10-05 9:04 ` Ramana Radhakrishnan 2018-10-16 16:14 ` Kristina Martsenko 2018-10-16 16:14 ` Kristina Martsenko 2018-10-19 11:35 ` Catalin Marinas 2018-10-19 11:35 ` Catalin Marinas 2018-10-19 11:47 ` Marc Zyngier 2018-10-19 11:47 ` Marc Zyngier 2018-10-19 12:22 ` Will Deacon 2018-10-19 12:22 ` Will Deacon 2018-10-19 14:42 ` Kristina Martsenko 2018-10-19 14:42 ` Kristina Martsenko 2018-10-19 15:10 ` Catalin Marinas 2018-10-19 15:10 ` Catalin Marinas 2018-10-19 17:45 ` Will Deacon 2018-10-19 17:45 ` Will Deacon 2018-11-02 6:02 ` Jon Masters 2018-11-02 6:02 ` Jon Masters 2018-10-24 10:56 ` Ramana Radhakrishnan 2018-10-24 10:56 ` Ramana Radhakrishnan 2018-10-15 22:35 ` Kees Cook 2018-10-15 22:35 ` Kees Cook 2018-11-02 9:46 ` Ramana Radhakrishnan 2018-11-02 9:46 ` Ramana Radhakrishnan 2018-10-05 8:47 ` [RFC 12/17] arm64: move ptrauth keys to thread_info Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-19 11:38 ` Catalin Marinas 2018-10-19 11:38 ` Catalin Marinas 2018-10-05 8:47 ` [RFC 13/17] arm64: install user ptrauth keys at kernel exit time Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-05 8:47 ` [RFC 14/17] arm64: unwind: strip PAC from kernel addresses Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-05 8:47 ` [RFC 15/17] arm64: enable ptrauth earlier Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-06 12:51 ` Amit Kachhap 2018-10-06 12:51 ` Amit Kachhap 2018-10-05 8:47 ` [RFC 16/17] arm64: initialize and switch ptrauth kernel keys Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-06 12:56 ` Amit Kachhap 2018-10-06 12:56 ` Amit Kachhap 2018-10-05 8:47 ` [RFC 17/17] arm64: compile the kernel with ptrauth -msign-return-address Kristina Martsenko 2018-10-05 8:47 ` Kristina Martsenko 2018-10-05 9:01 ` Ramana Radhakrishnan 2018-10-05 9:01 ` Ramana Radhakrishnan 2018-10-11 14:00 ` Kristina Martsenko 2018-10-11 14:00 ` Kristina Martsenko 2018-10-11 14:23 ` Vladimir Murzin 2018-10-11 14:23 ` Vladimir Murzin 2018-10-15 22:38 ` Kees Cook 2018-10-15 22:38 ` Kees Cook 2018-10-15 22:42 ` [PATCH 00/17] ARMv8.3 pointer authentication support Kees Cook 2018-10-15 22:42 ` Kees Cook 2018-11-13 16:17 ` Kristina Martsenko 2018-11-13 16:17 ` Kristina Martsenko 2018-11-13 23:09 ` Kees Cook 2018-11-13 23:09 ` Kees Cook 2018-11-14 15:54 ` Kristina Martsenko 2018-11-14 15:54 ` Kristina Martsenko 2018-11-14 21:47 ` Mark Rutland 2018-11-14 21:47 ` Mark Rutland 2018-11-14 22:48 ` Kees Cook 2018-11-14 22:48 ` Kees Cook 2018-10-19 12:36 ` Will Deacon 2018-10-19 12:36 ` Will Deacon 2018-10-23 8:39 ` Ramana Radhakrishnan [this message] 2018-10-23 8:39 ` Ramana Radhakrishnan
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=8478fc27-6e74-4fa6-7956-ffc1cca6c063@arm.com \ --to=ramana.radhakrishnan@arm.com \ --cc=Amit.Kachhap@arm.com \ --cc=Catalin.Marinas@arm.com \ --cc=Christoffer.Dall@arm.com \ --cc=Dave.Martin@arm.com \ --cc=Jacob.Bramley@arm.com \ --cc=Kristina.Martsenko@arm.com \ --cc=Marc.Zyngier@arm.com \ --cc=Mark.Rutland@arm.com \ --cc=Suzuki.Poulose@arm.com \ --cc=Will.Deacon@arm.com \ --cc=ard.biesheuvel@linaro.org \ --cc=arnd@arndb.de \ --cc=awallis@codeaurora.org \ --cc=drjones@redhat.com \ --cc=keescook@chromium.org \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.or \ /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: linkBe 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).