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=-10.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 9E627C63697 for ; Thu, 26 Nov 2020 18:46:36 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 376CA206B7 for ; Thu, 26 Nov 2020 18:46:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="zV3vjR/2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 376CA206B7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.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=OLlxfHkslFRSmCQziIrzrdAg5Z9PmI09gTubHlPE/bg=; b=zV3vjR/2JsMP7XjrZC2id5dyh yPufqPudqA4l9FUMdHjnyrQr8RqsbB1+7bM2BYdLoujx06s6yOHISHImMcVvM2NqOAkjJZV9peHfQ eQ1G4lb0TYDb/k421d6u741t80/F+e0mk1Tu/Gk6tu9FvuIIZfWMpDlcn7ajnlshD7f8p99zrUtOG lFVzEREb4YTJvIl6mCNkKrwnu9mbQKIeUTlZLdz1IblfDDLGdDrLiKNV7kYjPpXPIN0jkTnq+5tR4 C7W1SyuZJjsigcpiDD+u3DcknGJ2aaptI5QvkTCJkQPuRg7WayF6FbEuzoZo2MtWmx+D+RTB9JVtL uGqYTQdew==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kiMGD-0004tf-EO; Thu, 26 Nov 2020 18:44:53 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kiMF9-0004bj-64 for linux-arm-kernel@lists.infradead.org; Thu, 26 Nov 2020 18:43:48 +0000 Received: from gaia (unknown [95.146.230.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E21D121D1A; Thu, 26 Nov 2020 18:43:43 +0000 (UTC) Date: Thu, 26 Nov 2020 18:43:41 +0000 From: Catalin Marinas To: Peter Collingbourne Subject: Re: [PATCH v3] arm64: Introduce prctl(PR_PAC_{SET,GET}_ENABLED_KEYS) Message-ID: <20201126184341.GC6722@gaia> References: <20201119052011.3307433-1-pcc@google.com> <20201119180754.GM6882@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201126_134347_348684_32ED74D7 X-CRM114-Status: GOOD ( 23.10 ) 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: Andrey Konovalov , Kevin Brodsky , Kostya Serebryany , Evgenii Stepanov , Linux API , Vincenzo Frascino , Will Deacon , Dave Martin , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Nov 19, 2020 at 07:30:08PM -0800, Peter Collingbourne wrote: > On Thu, Nov 19, 2020 at 10:08 AM Dave Martin wrote: > > On Wed, Nov 18, 2020 at 09:20:11PM -0800, Peter Collingbourne wrote: > > > +void mte_thread_init_user(void) > > > { > > > if (!system_supports_mte()) > > > return; > > > @@ -121,7 +101,8 @@ void flush_mte_state(void) > > > write_sysreg_s(0, SYS_TFSRE0_EL1); > > > clear_thread_flag(TIF_MTE_ASYNC_FAULT); > > > /* disable tag checking */ > > > - set_sctlr_el1_tcf0(SCTLR_EL1_TCF0_NONE); > > > + set_task_sctlr_el1((current->thread.sctlr_user & ~SCTLR_EL1_TCF0_MASK) | > > > + SCTLR_EL1_TCF0_NONE); > > > > This (and the corresponding ptrauth init code) feels fragile. > > > > We modify some random bits in bits of code that aren't next to each > > other, and hope that they add up to the complete set of bits that are > > under user control. > > > > Can we add code to purge thread->sctlr_el1 to 0 before making these > > modifications or (perhaps simpler) just set it to a constant mask of the > > wanted bits? > > > > Failing that, can we at least move the relevant bits of code next to > > each other? > > That's basically the way I had things in v2 with init_sctlr. I agree > this is a bit fragile but it's how Catalin wanted it. To be honest I > slightly prefer the way the code was originally so maybe if it's 2 > against 1 we could go back to the original approach. The idea of init_sctlr as in v2 doesn't work that well since some bits may be toggled later via the cpufeature framework as secondary CPUs come up. We could update the final value as we finalise the CPU features, though I thought it's simpler if we keep this for the user-specific bits only. You'd need a mask anyway, unless you also maintain a master copy of the sctlr_el1 value for the kernel. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel