All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ardb@kernel.org>
To: "Catalin Marinas" <catalin.marinas@arm.com>,
	"Ard Biesheuvel" <ardb+git@google.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, "Will Deacon" <will@kernel.org>,
	maz@kernel.org, "Kevin Brodsky" <kevin.brodsky@arm.com>,
	"Mark Brown" <broonie@kernel.org>,
	"David Hildenbrand" <david@kernel.org>
Subject: Re: [PATCH 3/4] arm64: mte: Disregard the zero page explicitly for manipulating tags
Date: Thu, 04 Jun 2026 11:42:05 +0200	[thread overview]
Message-ID: <183c8a1e-abb7-4a2f-8e97-e161af4e4fc5@app.fastmail.com> (raw)
In-Reply-To: <aiFDFbeOoxgKigP0@arm.com>



On Thu, 4 Jun 2026, at 11:19, Catalin Marinas wrote:
> On Wed, Jun 03, 2026 at 06:09:53PM +0200, Ard Biesheuvel wrote:
>> From: Ard Biesheuvel <ardb@kernel.org>
>> 
>> 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 <ardb@kernel.org>
>> ---
>>  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()
>

True, but I was concerned about #inclusion hell.

>> +
>>  	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: <stable@vger.kernel.org> # 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.
>

Let's go with that - I'll turn this into a patch for v2


> -------------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

  reply	other threads:[~2026-06-04  9:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-03 16:09 [PATCH 0/4] fixes for data/bss linear alias unmap series Ard Biesheuvel
2026-06-03 16:09 ` [PATCH 1/4] arm64: Move generic KASAN page tables out of BSS too Ard Biesheuvel
2026-06-03 16:09 ` [PATCH 2/4] arm64: Avoid double evaluation of __ptep_get() Ard Biesheuvel
2026-06-03 16:09 ` [PATCH 3/4] arm64: mte: Disregard the zero page explicitly for manipulating tags Ard Biesheuvel
2026-06-04  9:19   ` Catalin Marinas
2026-06-04  9:42     ` Ard Biesheuvel [this message]
2026-06-03 16:09 ` [PATCH 4/4] arm64: mm: Defer remap of linear alias of data/bss Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=183c8a1e-abb7-4a2f-8e97-e161af4e4fc5@app.fastmail.com \
    --to=ardb@kernel.org \
    --cc=ardb+git@google.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=david@kernel.org \
    --cc=kevin.brodsky@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.