Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7008690imu; Wed, 14 Nov 2018 10:12:45 -0800 (PST) X-Google-Smtp-Source: AJdET5duT8w4g4WSARZIkeP+F/0H+3OhdP/s5jJHuuoQksagz2K8kILcAYT+pGrZSTCEMLUAPMYa X-Received: by 2002:a17:902:4827:: with SMTP id s36-v6mr2848177pld.226.1542219165101; Wed, 14 Nov 2018 10:12:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542219165; cv=none; d=google.com; s=arc-20160816; b=xQcgnkZkFJMq9wodfUzdLcoVVk5P8Cu346TTroMjlU/D8+YjZzY5+0IULPc93m6urz wnI/MHg5yNPUxYwCDosmNKKyLbX2iKprQYt0R5Uz2tktI5CzncM5Hyi6tarR2oRrU7hA dn/2GFN7KEw1m773af3SvHA9TE7duPDh0N7D0STIrzyfOiuuYHLP8QbRKYCynwFADzFO UL93p5zWzxYobilI3OLazdtg0MoSiiY1j5qt3ITqnuK2q/kc2Qe8Hz5lj2ZM8Lzco+d2 N9Ok+mC9QTngjUYlWPlPgJxgzmZnGKuqgtnPm9M+ZT3xNarrYvsK16gYsa3uCogYzXwW +S6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=CbFwGdldFnfPz8aF8IrcBVFPOMJP9JzOQ4HWpFTp9S4=; b=Ookw5aP/Q64Y+jd50Rnr4QUGHXaKCT/hiEdieqtFm/Ys2JpT6LYUpZtYYRHaQPHOEc Bu9WPhx4vqhn+vXpqz1F5HvZpDNBEaOeuEeqS3FG9GQRwsu9flCxSI8xBfgJosdh0YQY GexRq03662vCqRDq2QUSrQnKK+2lENc5Th1LDYfbFnhGVOkIJecZvlwDD849Rrk+qdBs bjXRBZbqd17DUINFyqaxzo4VDWSLoUM8MMmHTVHATwap7IJdJ3JvJhjXtq3UwrRSKtSR fG54Fflvlnh1pxCYLGeaqORqTukuR6gquKhuaWIFmkQLWd96nDUnksnxsZbDv7+xf0yv qiZQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o14si4080807pgj.59.2018.11.14.10.12.16; Wed, 14 Nov 2018 10:12:45 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728686AbeKOEP7 (ORCPT + 99 others); Wed, 14 Nov 2018 23:15:59 -0500 Received: from foss.arm.com ([217.140.101.70]:49118 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727576AbeKOEP6 (ORCPT ); Wed, 14 Nov 2018 23:15:58 -0500 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 875A4A78; Wed, 14 Nov 2018 10:11:43 -0800 (PST) Received: from brain-police (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B85593F718; Wed, 14 Nov 2018 10:11:40 -0800 (PST) Date: Wed, 14 Nov 2018 18:11:39 +0000 From: Will Deacon To: Catalin Marinas Cc: Kristina Martsenko , linux-arm-kernel@lists.infradead.org, Mark Rutland , linux-arch@vger.kernel.org, Andrew Jones , Jacob Bramley , Arnd Bergmann , Ard Biesheuvel , Marc Zyngier , Adam Wallis , "Suzuki K . Poulose" , Christoffer Dall , kvmarm@lists.cs.columbia.edu, Ramana Radhakrishnan , Amit Kachhap , Dave P Martin , linux-kernel@vger.kernel.org, Kees Cook , gorcunov@openvz.org Subject: Re: [PATCH v5 07/17] arm64: add basic pointer authentication support Message-ID: <20181114181138.GB2580@brain-police> References: <20181005084754.20950-1-kristina.martsenko@arm.com> <20181005084754.20950-8-kristina.martsenko@arm.com> <20181019111542.6wrvjguirglzg7vg@mbp> <20181019112404.GD14246@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181019112404.GD14246@arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, On Fri, Oct 19, 2018 at 12:24:04PM +0100, Will Deacon wrote: > On Fri, Oct 19, 2018 at 12:15:43PM +0100, Catalin Marinas wrote: > > On Fri, Oct 05, 2018 at 09:47:44AM +0100, Kristina Martsenko wrote: > > > diff --git a/arch/arm64/include/asm/pointer_auth.h b/arch/arm64/include/asm/pointer_auth.h > > > new file mode 100644 > > > index 000000000000..2aefedc31d9e > > > --- /dev/null > > > +++ b/arch/arm64/include/asm/pointer_auth.h > > > @@ -0,0 +1,63 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +#ifndef __ASM_POINTER_AUTH_H > > > +#define __ASM_POINTER_AUTH_H > > > + > > > +#include > > > + > > > +#include > > > +#include > > > + > > > +#ifdef CONFIG_ARM64_PTR_AUTH > > > +/* > > > + * Each key is a 128-bit quantity which is split across a pair of 64-bit > > > + * registers (Lo and Hi). > > > + */ > > > +struct ptrauth_key { > > > + unsigned long lo, hi; > > > +}; > > > + > > > +/* > > > + * We give each process its own instruction A key (APIAKey), which is shared by > > > + * all threads. This is inherited upon fork(), and reinitialised upon exec*(). > > > + * All other keys are currently unused, with APIBKey, APDAKey, and APBAKey > > > + * instructions behaving as NOPs. > > > + */ > > > > I don't remember the past discussions but I assume the tools guys are ok > > with a single key shared by multiple threads. Ramana, could you ack this > > part, FTR? > > > > (and it would help if someone from the Android and Chrome camps can > > confirm) > > 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. I managed to speak to the CRIU developers at LPC. The good news is that their preference is for a ptrace()-based interface for getting and setting the keys, so the only prctl() operation we need is to set a random key (separately for A and B). Will