From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 77A483859C9 for ; Thu, 4 Jun 2026 09:19:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780564762; cv=none; b=H3atdWt+i4mVv4u5kb4Q6DnHEVAOW7w9zoVukTOYNdtfqYyVhIQfl4qp+ZclIkeT1ZZhfarG9L8oO8lLq2Dv4mW/SOvs8Xe+KRUmYcJdYXygsvHuM/3rjn9A7vaffvCUW7sEGfsPr4NFet0PMYHGjPhujq46rD2l+MYK387PGPI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780564762; c=relaxed/simple; bh=FuZRWfARoBdxtqACAjhwFu//oki9peC1uE0VZ0XB/VM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cy3Hd7ace//nhkHVfcx0+p3lR4Pln99rYnSeDu0Co1v7BQN46Ay8H3REo/FKmOjVM0O8RsOkzfn+LynwAf+AYlK1KBy6GKEGn2GFWipvqSSs45z60F6vFLIU83Ew61ZHZuxBS2yGSIfzyE0aCA92x/QMlDg+axgCdNdnRxxHHTc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=YpHf3PZ+; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="YpHf3PZ+" 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 DB29C3297; Thu, 4 Jun 2026 02:19:15 -0700 (PDT) Received: from arm.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 981CA3F632; Thu, 4 Jun 2026 02:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1780564760; bh=FuZRWfARoBdxtqACAjhwFu//oki9peC1uE0VZ0XB/VM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YpHf3PZ+vQ0oVsa9roHjwkB+0vOR1Hexywzz1CyyUhwN9TlKNOk9yIjJTn07QHIMI LnnTh7Jc000KmvgsmMeoUjNqCdt88Mer6IMQ12ZA0UGvPWYCHYFbSElGxZXOpl4JwH gt9qV74qwQ9RRwoQaVzZY/ZgYuNAF3jaOipGlhwo= Date: Thu, 4 Jun 2026 10:19:17 +0100 From: Catalin Marinas To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, maz@kernel.org, Ard Biesheuvel , Kevin Brodsky , Mark Brown , David Hildenbrand Subject: Re: [PATCH 3/4] arm64: mte: Disregard the zero page explicitly for manipulating tags Message-ID: References: <20260603160949.3372482-6-ardb+git@google.com> <20260603160949.3372482-9-ardb+git@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260603160949.3372482-9-ardb+git@google.com> On Wed, Jun 03, 2026 at 06:09:53PM +0200, Ard Biesheuvel wrote: > From: Ard Biesheuvel > > The zero page is conceptually immutable, and will be moved into .rodata > to prevent inadvertent corruption. > > Prepare the MTE code for this, by ensuring that the zero page is never > taken into account for tag manipulation, given that those actions will > no longer be permitted on the read-only alias of .rodata in the linear > map. > > Signed-off-by: Ard Biesheuvel > --- > arch/arm64/include/asm/mte.h | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h > index 7f7b97e09996..093b34944aee 100644 > --- a/arch/arm64/include/asm/mte.h > +++ b/arch/arm64/include/asm/mte.h > @@ -80,6 +80,11 @@ static inline bool page_mte_tagged(struct page *page) > */ > static inline bool try_page_mte_tagging(struct page *page) > { > + extern struct page *__zero_page; > + > + if (page == __zero_page) > + return false; Better as is_zero_page() > + > VM_WARN_ON_ONCE(folio_test_hugetlb(page_folio(page))); > > if (!test_and_set_bit(PG_mte_lock, &page->flags.f)) Some form of this fix should have: Fixes: f620d66af316 ("arm64: mte: Do not flag the zero page as PG_mte_tagged") Cc: # 5.10.x The current mainline assumption is that mapping the zero page in user space is always mapped with pte_special() and we skip the MTE tag zeroing (and PG flag setting). However, the above commit missed the KVM kvm_s2_fault_map() -> sanitise_mte_tags() path and we don't have a form of pte_special() for stage 2 mappings. I'm more inclined to go with a specific test in the KVM path. It matches the stage 1 where we skip the actual tagging. We could add a VM_WARN_ONCE in try_page_mte_tagging() to trap future changes. -------------8<----------------------- diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index d089c107d9b7..445d6cf035c9 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -1479,6 +1479,11 @@ static void sanitise_mte_tags(struct kvm *kvm, kvm_pfn_t pfn, if (!kvm_has_mte(kvm)) return; + if (is_zero_pfn(pfn)) { + WARN_ON_ONCE(nr_pages != 1); + return; + } + if (folio_test_hugetlb(folio)) { /* Hugetlb has MTE flags set on head page only */ if (folio_try_hugetlb_mte_tagging(folio)) { -- Catalin