From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE13BECDE43 for ; Fri, 19 Oct 2018 16:16:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7183B20838 for ; Fri, 19 Oct 2018 16:16:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7183B20838 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727788AbeJTAXg (ORCPT ); Fri, 19 Oct 2018 20:23:36 -0400 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 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C042580D; Fri, 19 Oct 2018 09:16:48 -0700 (PDT) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 8FB273F71D; Fri, 19 Oct 2018 09:16:48 -0700 (PDT) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id AE6311AE06FD; Fri, 19 Oct 2018 17:16:51 +0100 (BST) Date: Fri, 19 Oct 2018 17:16:51 +0100 From: Will Deacon 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 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: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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