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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0ACDC433F5 for ; Thu, 7 Oct 2021 10:22:36 +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 B8A2E60F57 for ; Thu, 7 Oct 2021 10:22:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B8A2E60F57 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=MCaqNLV9oU1gJXdiuc1Cq98lDsvt/O3D/zbOiLRAKJw=; b=2jyXZQjavqsPRR T1rvOEWh28zHQW1x9GG5VdtruBprk05Wu7E10l5WccRpIBd3Yos7o3sM8WTPO/vjtwk3qnlPTPpdI zzjR3zlb3rm4+F6JvgX7/cjB3c6ecfkmJ8nmmRIkwnxj60gUqjClCK8in6uKtTcIxW3TilnDiHcpJ nLjc9Uc5DFXyW26zJsr8MBB36jch1X5nkQNU+2cUGAfGa0ci7A3lNp273ohi3tZEabst+niUOuVhw ba5XaZs1LsnBGF90Sc+4gzM8tTGcHYC6J/R4BFaQot3B3nWNCpDoCsLW2YhCuGNDDfTJdXZ5WgNRV J6ch/ruV5/LdDzKoSOOw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mYQW2-00GsCb-L7; Thu, 07 Oct 2021 10:20:42 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mYQVy-00GsB7-VC for linux-arm-kernel@lists.infradead.org; Thu, 07 Oct 2021 10:20:40 +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 2C9736D; Thu, 7 Oct 2021 03:20:33 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.19.57]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CC88B3F766; Thu, 7 Oct 2021 03:20:31 -0700 (PDT) Date: Thu, 7 Oct 2021 11:20:29 +0100 From: Mark Rutland To: Peter Collingbourne Cc: Catalin Marinas , Vincenzo Frascino , Will Deacon , Andrey Konovalov , Evgenii Stepanov , Linux ARM Subject: Re: [PATCH] arm64: mte: avoid clearing PSTATE.TCO on entry unless necessary Message-ID: <20211007102029.GB45209@C02TD0UTHF1T.local> References: <20210929194525.3252555-1-pcc@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211007_032039_141917_C90BAF1C X-CRM114-Status: GOOD ( 35.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Tue, Oct 05, 2021 at 12:08:58PM -0700, Peter Collingbourne wrote: > On Tue, Oct 5, 2021 at 9:46 AM Catalin Marinas wrote: > > On Wed, Sep 29, 2021 at 12:45:24PM -0700, Peter Collingbourne wrote: > > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S > > > index 2f69ae43941d..85ead6bbb38e 100644 > > > --- a/arch/arm64/kernel/entry.S > > > +++ b/arch/arm64/kernel/entry.S > > > @@ -269,7 +269,28 @@ alternative_else_nop_endif > > > .else > > > add x21, sp, #PT_REGS_SIZE > > > get_current_task tsk > > > + ldr x0, [tsk, THREAD_SCTLR_USER] > > > .endif /* \el == 0 */ > > > + > > > + /* > > > + * Re-enable tag checking (TCO set on exception entry). This is only > > > + * necessary if MTE is enabled in either the kernel or the userspace > > > + * task in synchronous mode. With MTE disabled in the kernel and > > > + * disabled or asynchronous in userspace, tag check faults (including in > > > + * uaccesses) are not reported, therefore there is no need to re-enable > > > + * checking. This is beneficial on microarchitectures where re-enabling > > > + * TCO is expensive. > > > + */ > > > +#ifdef CONFIG_ARM64_MTE > > > +alternative_cb kasan_hw_tags_enable > > > + tbz x0, #SCTLR_EL1_TCF0_SHIFT, 1f > > > +alternative_cb_end > > > +alternative_if ARM64_MTE > > > + SET_PSTATE_TCO(0) > > > +alternative_else_nop_endif > > > +1: > > > +#endif > > > > I think we can get here from an interrupt as well. Can we guarantee that > > the sctlr_user is valid? We are not always in a user process context. > > Looking through the code in entry.S carefully it doesn't appear that > the tsk pointer is ever used when taking an exception from EL1. The > last user appears to have been removed in commit 3d2403fd10a1 ("arm64: > uaccess: remove set_fs()"). I just did a quick boot test on a couple > of platforms and things seem to work without the "get_current_task > tsk" line. > > So I can't be confident that tsk points to a valid task, but at least > it looks like it was the case prior to that commit. > > > Maybe only do the above checks if \el == 0, otherwise just bracket it > > with kasan_hw_tags_enable. > > Is it possible for us to do a uaccess inside the EL1 -> EL1 exception > handler? That was the one thing I was unsure about and it's why I > opted to do the same check regardless of EL. Today we can do so if we take a PMU IRQ from EL1 and try to do an EL0 stack unwind or stack dump, and similar holds for some eBPF stuff. We also need to ensure that PSTATE.TCO is configured consistently so that context-switch works, otherwise where a CPU switches between tasks A and B, where A is preempted by an EL1 IRQ, and B is explicitly switching via a direct call to schedule(), the state of TCO will not be as expected (unless we track this per thread, and handle it in the context switch). I'd strongly prefer that the state of PSTATE.TCO upon taking an exception to EL1 is consistent (by the end of the early entry code), regardless of where that was taken from. Is it easier to manage this from within entry-common.c? Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel