(cc Marc) On Tue, 2 Jun 2026, at 22:34, Will Deacon wrote: > On Fri, 29 May 2026 17:01:51 +0200, Ard Biesheuvel wrote: >> One of the reasons the lack of randomization of the linear map on arm64 >> is considered problematic is the fact that bootloaders adhering to the >> original arm64 boot protocol (i.e., a substantial fraction of all >> Android phones) may place the kernel at the base of DRAM, and therefore >> at the base of the non-randomized linear map. This puts a writable alias >> of the kernel's data and bss regions at a predictable location, removing >> the need for an attacker to guess where KASLR mapped the kernel. >> >> [...] > > It would've been nice to hear from the ppc folks on patch 11, but I've > picked it up on the assumption that they'll love the negative diff stat. > Worst case, we can drop/revert stuff if they have late objections. >
Thanks. There is a de facto ack from Michael Ellerman in the Link:, which is why I included it. Note that Sashiko found an issue with KVM+MTE, where a read-only mapping of the zero page in the linear map may result in issues: """ Does moving the zero page to .rodata (or unmapping/read-only mapping its linear alias) expose a guest-to-host denial of service with KVM and MTE? When an MTE-enabled KVM guest reads an unmapped memory address, KVM handles the stage-2 fault by mapping the host's shared zero page. KVM will then call sanitise_mte_tags() in arch/arm64/kvm/mmu.c. Since the PG_mte_tagged flag is never set on the zero page, KVM's try_page_mte_tagging() succeeds, and it calls mte_clear_page_tags(). This executes the STGM instruction using the zero page's linear map alias. If this alias is read-only or unmapped, won't the STGM instruction trigger a synchronous permission fault or translation fault in EL1, causing a host kernel panic? """ Marc seems to think it is legit, so I came up with the following (I'll send it out separately with another pair of tweaks): -------8<------------ From: Ard Biesheuvel <[email protected]> Subject: [PATCH] arm64: mte: Disregard the zero page explicitly for manipulating tags 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 <[email protected]> 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; + VM_WARN_ON_ONCE(folio_test_hugetlb(page_folio(page))); if (!test_and_set_bit(PG_mte_lock, &page->flags.f))
