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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 28054CD13CF for ; Mon, 2 Sep 2024 19:09:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=pn2nVuJ3P3f/HSlVJLpRyhFtgyUbvXYluAUxlc8oLnk=; b=nmjZU6CHXiHdKqINnGJH+JlhmU HHVpBmsFQkMQ2IGRNZ9GdbI59ThLbKMOW+NhjE/x5SFxWQ6iYzqb7rZHF92lelzG2SO1PLPUjw732 WNW+y30lMu1ua1ClSHb+AxilcDqBYVmxfF6iTaAf6W8Hv3AwRz3n3MltGFnAgmW4pTTNJxC7HrFVk tc1I82Dv/zXhg/2tc+uexz2ipP4P3Y+PiFrGcCtd6wtZklw6lLCkgZLgN8CA7f4cbIFubFjF+kli9 f8jnM8APDNAhYG44Wyere1TTZzSHhei4tMGxg5PTmvI/TSkB51/bHijzFOLGbrZ0ReAgzVwl3CYYS QpmR1o/w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1slCQP-0000000FMq4-3d5y; Mon, 02 Sep 2024 19:09:17 +0000 Received: from nyc.source.kernel.org ([147.75.193.91]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1slCPR-0000000FMRi-0IkP for linux-arm-kernel@lists.infradead.org; Mon, 02 Sep 2024 19:08:18 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 6BE76A431C9; Mon, 2 Sep 2024 19:08:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7FCD8C4CEC2; Mon, 2 Sep 2024 19:08:10 +0000 (UTC) Date: Mon, 2 Sep 2024 20:08:08 +0100 From: Catalin Marinas To: Will Deacon Cc: Joey Gouly , linux-arm-kernel@lists.infradead.org, nd@arm.com, akpm@linux-foundation.org, aneesh.kumar@kernel.org, aneesh.kumar@linux.ibm.com, anshuman.khandual@arm.com, bp@alien8.de, broonie@kernel.org, christophe.leroy@csgroup.eu, dave.hansen@linux.intel.com, hpa@zytor.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, maz@kernel.org, mingo@redhat.com, mpe@ellerman.id.au, naveen.n.rao@linux.ibm.com, npiggin@gmail.com, oliver.upton@linux.dev, shuah@kernel.org, skhan@linuxfoundation.org, szabolcs.nagy@arm.com, tglx@linutronix.de, x86@kernel.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v5 06/30] arm64: context switch POR_EL0 register Message-ID: References: <20240822151113.1479789-1-joey.gouly@arm.com> <20240822151113.1479789-7-joey.gouly@arm.com> <20240823144531.GH32156@willie-the-truck> <20240823170835.GA1181@willie-the-truck> <20240827113803.GB4318@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240827113803.GB4318@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240902_120817_196988_9317D122 X-CRM114-Status: GOOD ( 22.41 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Aug 27, 2024 at 12:38:04PM +0100, Will Deacon wrote: > On Fri, Aug 23, 2024 at 07:40:52PM +0100, Catalin Marinas wrote: > > On Fri, Aug 23, 2024 at 06:08:36PM +0100, Will Deacon wrote: > > > On Fri, Aug 23, 2024 at 05:41:06PM +0100, Catalin Marinas wrote: > > > > On Fri, Aug 23, 2024 at 03:45:32PM +0100, Will Deacon wrote: > > > > > On Thu, Aug 22, 2024 at 04:10:49PM +0100, Joey Gouly wrote: > > > > > > +static void permission_overlay_switch(struct task_struct *next) > > > > > > +{ > > > > > > + if (!system_supports_poe()) > > > > > > + return; > > > > > > + > > > > > > + current->thread.por_el0 = read_sysreg_s(SYS_POR_EL0); > > > > > > + if (current->thread.por_el0 != next->thread.por_el0) { > > > > > > + write_sysreg_s(next->thread.por_el0, SYS_POR_EL0); > > > > > > + /* ISB required for kernel uaccess routines when chaning POR_EL0 */ > > > > > > > > > > nit: typo "chaning". > > > > > > > > > > But more substantially, is this just to prevent spurious faults in the > > > > > context of a new thread using a stale value for POR_EL0? > > > > > > > > Not just prevent faults but enforce the permissions from the new > > > > thread's POR_EL0. The kernel may continue with a uaccess routine from > > > > here, we can't tell. [...] > > > So what do we actually gain by having the uaccess routines honour this? > > > > I guess where it matters is more like not accidentally faulting because > > the previous thread had more restrictive permissions. > > That's what I wondered initially, but won't the fault handler retry in > that case? Yes, it will retry and this should be fine (I assume you are only talking about the dropping ISB in the context switch). For the case of running with a more permissive stale POR_EL0, arguably it's slightly more predictable for the user but, OTOH, some syscalls like readv() could be routed through GUP with no checks. As with MTE, we don't guarantee uaccesses honour the user permissions. That said, at some point we should sanitise this path anyway and have a single ISB at the end. In the meantime, I'm fine with dropping the ISB here. -- Catalin