From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:55758 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727219AbeJTAXf (ORCPT ); Fri, 19 Oct 2018 20:23:35 -0400 Date: Fri, 19 Oct 2018 17:16:51 +0100 From: Will Deacon Subject: Re: [PATCH v5 07/17] arm64: add basic pointer authentication support Message-ID: <20181019161651.GE16771@arm.com> References: <20181005084754.20950-1-kristina.martsenko@arm.com> <20181005084754.20950-8-kristina.martsenko@arm.com> <20181019111542.6wrvjguirglzg7vg@mbp> <20181019112404.GD14246@arm.com> <20181019154948.GD16771@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Kees Cook Cc: Mark Rutland , linux-arch , Andrew Jones , LKML , Jacob Bramley , Arnd Bergmann , Ard Biesheuvel , Marc Zyngier , Catalin Marinas , Adam Wallis , "Suzuki K . Poulose" , Christoffer Dall , Kristina Martsenko , Dave P Martin , Cyrill Gorcunov , Ramana Radhakrishnan , Amit Kachhap , kvmarm@lists.cs.columbia.edu, linux-arm-kernel Message-ID: <20181019161651.P3iB5V4Mou6EJfcX_2ISqx2j4jRvnZbJOmFDaDnwY6s@z> On Fri, Oct 19, 2018 at 09:05:57AM -0700, Kees Cook wrote: > On Fri, Oct 19, 2018 at 8:49 AM, Will Deacon wrote: > > On Fri, Oct 19, 2018 at 08:36:45AM -0700, Kees Cook wrote: > >> On Fri, Oct 19, 2018 at 4:24 AM, Will Deacon 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? > > I mean if it's starting a new thread, it should get a new key > automatically, just like the ssp canary happens in dup_task_struct(). > > (Or did I miss some context for why that's not possible?) The problem with that is if the child thread (in userspace) returns from the function that called fork(), then it will explode because the link register will have been signed with the parent key. Will