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.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=unavailable 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 9F697C31E49 for ; Thu, 13 Jun 2019 15:26:59 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7528E2082C for ; Thu, 13 Jun 2019 15:26:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="HATfwqPW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7528E2082C 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-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=w4J2Mjgz2guoB6VUnu6ftl+LZT2uj+S/mJ2GqtNnfOc=; b=HATfwqPWGxgx5j Svfh7LudEyavVLnacm8+hOlmNI/gDBuIBXXl9JEP0Rb7wpYUJESYBioON5X5nhETJmwDFggj1tVKz 03swrCW7yJvkLLCE4kNld7LozFEahWaJLNk16Y+Z4m8cSQpkcb7ArpFOpeSPwO7RWSQlZOPlMfbzR Hz0YU+SErx6/6QAIoe1S1gFbFdDvCMCEcQOtodmD+hYS+Iz6IBtzBClk149dkRTE1OieDo6Hoxp0I ECPHKP1AMwyzOU1w6Int81/ydVe+p0VrobNOX4fyarK3Fn9b9Rd6gNxclexVx33UjurahWRVUM2ix E13DQdBSCLFF/gFrE08Q==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hbRcu-00025L-Es; Thu, 13 Jun 2019 15:26:56 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hbRcr-000241-1W for linux-arm-kernel@lists.infradead.org; Thu, 13 Jun 2019 15:26:54 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A46BD3EF; Thu, 13 Jun 2019 08:26:49 -0700 (PDT) Received: from C02TF0J2HF1T.local (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3FA233F718; Thu, 13 Jun 2019 08:26:36 -0700 (PDT) Date: Thu, 13 Jun 2019 16:26:32 +0100 From: Catalin Marinas To: Dave Martin Subject: Re: [PATCH v17 03/15] arm64: Introduce prctl() options to control the tagged user addresses ABI Message-ID: <20190613152632.GT28951@C02TF0J2HF1T.local> References: <20190613110235.GW28398@e103592.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190613110235.GW28398@e103592.cambridge.arm.com> User-Agent: Mutt/1.11.2 (2019-01-07) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190613_082653_177709_D63C6697 X-CRM114-Status: GOOD ( 26.93 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , kvm@vger.kernel.org, Christian Koenig , Szabolcs Nagy , Will Deacon , dri-devel@lists.freedesktop.org, Kostya Serebryany , Khalid Aziz , Lee Smith , linux-kselftest@vger.kernel.org, Vincenzo Frascino , Jacob Bramley , Leon Romanovsky , linux-rdma@vger.kernel.org, amd-gfx@lists.freedesktop.org, Christoph Hellwig , Jason Gunthorpe , Dmitry Vyukov , Evgeniy Stepanov , linux-media@vger.kernel.org, Kees Cook , Ruben Ayrapetyan , Andrey Konovalov , Kevin Brodsky , Alex Williamson , Mauro Carvalho Chehab , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, Greg Kroah-Hartman , Felix Kuehling , linux-kernel@vger.kernel.org, Jens Wiklander , Ramana Radhakrishnan , Alexander Deucher , Andrew Morton , enh , Robin Murphy , Yishai Hadas , Luc Van Oostenryck Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Dave, On Thu, Jun 13, 2019 at 12:02:35PM +0100, Dave P Martin wrote: > On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote: > > +/* > > + * Global sysctl to disable the tagged user addresses support. This control > > + * only prevents the tagged address ABI enabling via prctl() and does not > > + * disable it for tasks that already opted in to the relaxed ABI. > > + */ > > +static int zero; > > +static int one = 1; > > !!! > > And these can't even be const without a cast. Yuk. > > (Not your fault though, but it would be nice to have a proc_dobool() to > avoid this.) I had the same reaction. Maybe for another patch sanitising this pattern across the kernel. > > --- a/include/uapi/linux/prctl.h > > +++ b/include/uapi/linux/prctl.h > > @@ -229,4 +229,9 @@ struct prctl_mm_map { > > # define PR_PAC_APDBKEY (1UL << 3) > > # define PR_PAC_APGAKEY (1UL << 4) > > > > +/* Tagged user address controls for arm64 */ > > +#define PR_SET_TAGGED_ADDR_CTRL 55 > > +#define PR_GET_TAGGED_ADDR_CTRL 56 > > +# define PR_TAGGED_ADDR_ENABLE (1UL << 0) > > + > > Do we expect this prctl to be applicable to other arches, or is it > strictly arm64-specific? I kept it generic, at least the tagged address part. The MTE bits later on would be arm64-specific. > > @@ -2492,6 +2498,16 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3, > > return -EINVAL; > > error = PAC_RESET_KEYS(me, arg2); > > break; > > + case PR_SET_TAGGED_ADDR_CTRL: > > + if (arg3 || arg4 || arg5) > > > > How do you anticipate these arguments being used in the future? I don't expect them to be used at all. But since I'm not sure, I'd force them as zero for now rather than ignored. The GET is supposed to return the SET arg2, hence I'd rather not used the other arguments. > For the SVE prctls I took the view that "get" could only ever mean one > thing, and "put" already had a flags argument with spare bits for future > expansion anyway, so forcing the extra arguments to zero would be > unnecessary. > > Opinions seem to differ on whether requiring surplus arguments to be 0 > is beneficial for hygiene, but the glibc prototype for prctl() is > > int prctl (int __option, ...); > > so it seemed annoying to have to pass extra arguments to it just for the > sake of it. IMHO this also makes the code at the call site less > readable, since it's not immediately apparent that all those 0s are > meaningless. It's fine by me to ignore the other arguments. I just followed the pattern of some existing prctl options. I don't have a strong opinion either way. > > + return -EINVAL; > > + error = SET_TAGGED_ADDR_CTRL(arg2); > > + break; > > + case PR_GET_TAGGED_ADDR_CTRL: > > + if (arg2 || arg3 || arg4 || arg5) > > + return -EINVAL; > > + error = GET_TAGGED_ADDR_CTRL(); > > Having a "get" prctl is probably a good idea, but is there a clear > usecase for it? Not sure, maybe some other library (e.g. a JIT compiler) would like to check whether tagged addresses have been enabled during application start and decide to generate tagged pointers for itself. It seemed pretty harmless, unless we add more complex things to the prctl() that cannot be returned in one request). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel