From: Will Deacon <will.deacon@arm.com> To: Kees Cook <keescook@chromium.org> Cc: Catalin Marinas <catalin.marinas@arm.com>, Kristina Martsenko <kristina.martsenko@arm.com>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Mark Rutland <mark.rutland@arm.com>, linux-arch <linux-arch@vger.kernel.org>, Andrew Jones <drjones@redhat.com>, Jacob Bramley <jacob.bramley@arm.com>, Arnd Bergmann <arnd@arndb.de>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Marc Zyngier <marc.zyngier@arm.com>, Adam Wallis <awallis@codeaurora.org>, "Suzuki K . Poulose" <suzuki.poulose@arm.com>, Christoffer Dall <christoffer.dall@arm.com>, kvmarm@lists.cs.columbia.edu, Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>, Amit Kachhap <Amit.Kachhap@arm.com>, Dave P Martin <Dave.Martin@arm.com>, LKML <linux-kernel@vger.kernel.org>, Cyrill Subject: Re: [PATCH v5 07/17] arm64: add basic pointer authentication support Date: Fri, 19 Oct 2018 16:49:48 +0100 [thread overview] Message-ID: <20181019154948.GD16771@arm.com> (raw) In-Reply-To: <CAGXu5j+2axuzPJji_eCvMZDiPvrPsP3kAnG0CY_rsL5c=uFQFA@mail.gmail.com> On Fri, Oct 19, 2018 at 08:36:45AM -0700, Kees Cook wrote: > On Fri, Oct 19, 2018 at 4:24 AM, Will Deacon <will.deacon@arm.com> wrote: > > FWIW: I think we should be entertaining a prctl() interface to use a new > > key on a per-thread basis. Obviously, this would need to be used with care > > (e.g. you'd fork(); use the prctl() and then you'd better not return from > > the calling function!). > > > > Assuming we want this (Kees -- I was under the impression that everything in > > Android would end up with the same key otherwise?), then the question is > > do we want: > > > > - prctl() get/set operations for the key, or > > - prctl() set_random_key operation, or > > - both of the above? > > > > Part of the answer to that may lie in the requirements of CRIU, where I > > strongly suspect they need explicit get/set operations, although these > > could be gated on CONFIG_CHECKPOINT_RESTORE=y. > > Oh CRIU. Yikes. I'd like the get/set to be gated by the CONFIG, yes. > No reason to allow explicit access to the key (and selected algo) if > we don't have to. Makes sense. > As for per-thread or not, having a "pick a new key now" prctl() sounds > good, but I'd like to have an eye toward having it just be "automatic" > on clone(). I thought about that too, but we're out of clone() flags afaict and there's no arch hook in there. We could add yet another clone syscall, but yuck (and I reckon viro would kill us). Or are you saying that we could infer the behaviour from the existing set of flags? Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com> To: Kees Cook <keescook@chromium.org> Cc: Catalin Marinas <catalin.marinas@arm.com>, Kristina Martsenko <kristina.martsenko@arm.com>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Mark Rutland <mark.rutland@arm.com>, linux-arch <linux-arch@vger.kernel.org>, Andrew Jones <drjones@redhat.com>, Jacob Bramley <jacob.bramley@arm.com>, Arnd Bergmann <arnd@arndb.de>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Marc Zyngier <marc.zyngier@arm.com>, Adam Wallis <awallis@codeaurora.org>, "Suzuki K . Poulose" <suzuki.poulose@arm.com>, Christoffer Dall <christoffer.dall@arm.com>, kvmarm@lists.cs.columbia.edu, Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>, Amit Kachhap <Amit.Kachhap@arm.com>, Dave P Martin <Dave.Martin@arm.com>, LKML <linux-kernel@vger.kernel.org>, Cyrill Gorcunov <gorcunov@openvz.org> Subject: Re: [PATCH v5 07/17] arm64: add basic pointer authentication support Date: Fri, 19 Oct 2018 16:49:48 +0100 [thread overview] Message-ID: <20181019154948.GD16771@arm.com> (raw) Message-ID: <20181019154948.03lzC3N4FZGJw4L3RpjqtrxRojk-fSzeOvYxEuG75sg@z> (raw) In-Reply-To: <CAGXu5j+2axuzPJji_eCvMZDiPvrPsP3kAnG0CY_rsL5c=uFQFA@mail.gmail.com> On Fri, Oct 19, 2018 at 08:36:45AM -0700, Kees Cook wrote: > On Fri, Oct 19, 2018 at 4:24 AM, Will Deacon <will.deacon@arm.com> wrote: > > FWIW: I think we should be entertaining a prctl() interface to use a new > > key on a per-thread basis. Obviously, this would need to be used with care > > (e.g. you'd fork(); use the prctl() and then you'd better not return from > > the calling function!). > > > > Assuming we want this (Kees -- I was under the impression that everything in > > Android would end up with the same key otherwise?), then the question is > > do we want: > > > > - prctl() get/set operations for the key, or > > - prctl() set_random_key operation, or > > - both of the above? > > > > Part of the answer to that may lie in the requirements of CRIU, where I > > strongly suspect they need explicit get/set operations, although these > > could be gated on CONFIG_CHECKPOINT_RESTORE=y. > > Oh CRIU. Yikes. I'd like the get/set to be gated by the CONFIG, yes. > No reason to allow explicit access to the key (and selected algo) if > we don't have to. Makes sense. > As for per-thread or not, having a "pick a new key now" prctl() sounds > good, but I'd like to have an eye toward having it just be "automatic" > on clone(). I thought about that too, but we're out of clone() flags afaict and there's no arch hook in there. We could add yet another clone syscall, but yuck (and I reckon viro would kill us). Or are you saying that we could infer the behaviour from the existing set of flags? Will
next prev parent reply other threads:[~2018-10-19 15:49 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 [this message] 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 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=20181019154948.GD16771@arm.com \ --to=will.deacon@arm.com \ --cc=Amit.Kachhap@arm.com \ --cc=Dave.Martin@arm.com \ --cc=ard.biesheuvel@linaro.org \ --cc=arnd@arndb.de \ --cc=awallis@codeaurora.org \ --cc=catalin.marinas@arm.com \ --cc=christoffer.dall@arm.com \ --cc=drjones@redhat.com \ --cc=jacob.bramley@arm.com \ --cc=keescook@chromium.org \ --cc=kristina.martsenko@arm.com \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=marc.zyngier@arm.com \ --cc=mark.rutland@arm.com \ --cc=ramana.radhakrishnan@arm.com \ --cc=suzuki.poulose@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: 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).