From: "Ard Biesheuvel" <ardb@kernel•org>
To: "Will Deacon" <will@kernel•org>,
linux-arm-kernel@lists•infradead.org,
"Ard Biesheuvel" <ardb+git@google•com>
Cc: "Catalin Marinas" <catalin.marinas@arm•com>,
kernel-team@android•com, linux-kernel@vger•kernel.org,
"Mark Rutland" <mark.rutland@arm•com>,
"Ryan Roberts" <ryan.roberts@arm•com>,
"Anshuman Khandual" <anshuman.khandual@arm•com>,
"Kevin Brodsky" <kevin.brodsky@arm•com>,
"Liz Prucka" <lizprucka@google•com>,
"Seth Jenkins" <sethjenkins@google•com>,
"Kees Cook" <kees@kernel•org>, "Mike Rapoport" <rppt@kernel•org>,
"David Hildenbrand" <david@kernel•org>,
"Andrew Morton" <akpm@linux-foundation•org>,
"Jann Horn" <jannh@google•com>,
linux-mm@kvack•org, linux-hardening@vger•kernel.org,
linuxppc-dev@lists•ozlabs.org, linux-sh@vger•kernel.org,
maz@kernel•org
Subject: Re: [PATCH v7 00/15] arm64: Unmap linear alias of kernel data/bss
Date: Wed, 03 Jun 2026 10:57:49 +0200 [thread overview]
Message-ID: <2c7929d4-6622-475d-af1b-bcd0cd997cd3@app.fastmail.com> (raw)
In-Reply-To: <178041415770.4024555.11336437584927054639.b4-ty@kernel.org>
(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 <ardb@kernel•org>
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 <ardb@kernel•org>
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))
next prev parent reply other threads:[~2026-06-03 8:58 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-29 15:01 [PATCH v7 00/15] arm64: Unmap linear alias of kernel data/bss Ard Biesheuvel
2026-05-29 15:01 ` [PATCH v7 01/15] arm64: mm: Remove bogus stop condition from map_mem() loop Ard Biesheuvel
2026-05-29 15:01 ` [PATCH v7 02/15] arm64: mm: Drop redundant pgd_t* argument from map_mem() Ard Biesheuvel
2026-05-29 15:01 ` [PATCH v7 03/15] arm64: mm: Check for pud_/pmd_set_huge() failures on kernel mappings Ard Biesheuvel
2026-05-29 15:01 ` [PATCH v7 04/15] arm64: mm: Preserve existing table mappings when mapping DRAM Ard Biesheuvel
2026-05-29 15:01 ` [PATCH v7 05/15] arm64: mm: Preserve non-contiguous descriptors " Ard Biesheuvel
2026-05-29 15:01 ` [PATCH v7 06/15] arm64: mm: Permit contiguous descriptors to be manipulated Ard Biesheuvel
2026-05-29 15:01 ` [PATCH v7 07/15] arm64: kfence: Avoid NOMAP tricks when mapping the early pool Ard Biesheuvel
2026-06-01 10:42 ` Kevin Brodsky
2026-05-29 15:01 ` [PATCH v7 08/15] arm64: mm: Permit contiguous attribute for preliminary mappings Ard Biesheuvel
2026-05-29 15:02 ` [PATCH v7 09/15] arm64: Move fixmap and kasan page tables to end of kernel image Ard Biesheuvel
2026-05-29 15:02 ` [PATCH v7 10/15] arm64: mm: Don't abuse memblock NOMAP to check for overlaps Ard Biesheuvel
2026-06-01 10:43 ` Kevin Brodsky
2026-05-29 15:02 ` [PATCH v7 11/15] powerpc/code-patching: Avoid r/w mapping of the zero page Ard Biesheuvel
2026-06-03 18:03 ` Mukesh Kumar Chaurasiya
2026-06-04 7:43 ` Christophe Leroy (CS GROUP)
2026-05-29 15:02 ` [PATCH v7 12/15] sh: Drop cache flush of the zero page at boot Ard Biesheuvel
2026-05-30 16:19 ` Mike Rapoport
2026-06-01 8:11 ` Geert Uytterhoeven
2026-05-29 15:02 ` [PATCH v7 13/15] mm: Make empty_zero_page[] const Ard Biesheuvel
2026-05-29 15:02 ` [PATCH v7 14/15] arm64: mm: Map the kernel data/bss read-only in the linear map Ard Biesheuvel
2026-05-29 15:02 ` [PATCH v7 15/15] arm64: mm: Unmap kernel data/bss entirely from " Ard Biesheuvel
2026-06-01 10:43 ` Kevin Brodsky
2026-06-02 20:34 ` [PATCH v7 00/15] arm64: Unmap linear alias of kernel data/bss Will Deacon
2026-06-03 8:57 ` Ard Biesheuvel [this message]
2026-06-03 11:22 ` Will Deacon
2026-06-03 11:24 ` 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=2c7929d4-6622-475d-af1b-bcd0cd997cd3@app.fastmail.com \
--to=ardb@kernel$(echo .)org \
--cc=akpm@linux-foundation$(echo .)org \
--cc=anshuman.khandual@arm$(echo .)com \
--cc=ardb+git@google$(echo .)com \
--cc=catalin.marinas@arm$(echo .)com \
--cc=david@kernel$(echo .)org \
--cc=jannh@google$(echo .)com \
--cc=kees@kernel$(echo .)org \
--cc=kernel-team@android$(echo .)com \
--cc=kevin.brodsky@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-hardening@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-mm@kvack$(echo .)org \
--cc=linux-sh@vger$(echo .)kernel.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=lizprucka@google$(echo .)com \
--cc=mark.rutland@arm$(echo .)com \
--cc=maz@kernel$(echo .)org \
--cc=rppt@kernel$(echo .)org \
--cc=ryan.roberts@arm$(echo .)com \
--cc=sethjenkins@google$(echo .)com \
--cc=will@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox