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 DDBD1CD6E64 for ; Wed, 3 Jun 2026 08:58:23 +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:Content-Transfer-Encoding: Content-Type:Subject:References:In-Reply-To:Message-Id:Cc:To:From:Date: MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=HNO5aQb0rtRKtux/wu+5AcytYSH9RtOlt3U0qrUIzPI=; b=1Mb3w0zYQJ0yHqXeqQlS1nmbgx LvK8rppR87JIFtvh/7Oonk0IIqMgOM/inOBDaAI/uAjqvsOoOU4QjAQ1Iv/eVgIs12zE8aBDb63uC xaC0YtITp96hR5zqdtmg02xTACmmhP6QT2etPjp8pY7Ybsp8xRXMl3yo2jQXNG80fE/D+Hqd3Y0VN 3UZiqI4jJqe4iUD/WVCxotFtdbydU3Tx2NfyNG8NtBgvhuY3vUChgtPZNOrjb+WtxdlF15Ikrpiui wXTY8Jyp+nulx2yulqRzBj/CLrx+EMHpKvLvjfZHsy//30XrGZrpVKJZr7jAvZi6UU6ypad4//7el HYZenKZQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wUhQW-0000000Eela-2aiU; Wed, 03 Jun 2026 08:58:16 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wUhQU-0000000EelC-1zml for linux-arm-kernel@lists.infradead.org; Wed, 03 Jun 2026 08:58:15 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 71350434B2; Wed, 3 Jun 2026 08:58:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 924931F00899; Wed, 3 Jun 2026 08:58:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780477092; bh=HNO5aQb0rtRKtux/wu+5AcytYSH9RtOlt3U0qrUIzPI=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=mnPkKyEgBAoJhHyCjKocF+n+JqkHcWSmPH184p/CrskKjSd4JLPoFSBGrYLKU9Mar B1hI8HW9H+53ks3lghDx4U+J6rNa6f8KquouzDq0+DM7/4ZBRzC0AuXQVPvI5bKqkY NglLbcu+ZBDleA+IgNkKfEKOPcXRhxVfSNk8lTpECqvKoBh+iHSyU2ZFRwFPFE4daX kw0WCczgVzTNS8Nry/XjBs//vr21nJLOAmz9iMERtpe8gUl3WYdzTVYvcHDMtqVnlJ wu/GIoZWa0/6+fA9X2Sm0u6y0MnNMo3tVdcswt4ZtD+mHXcn/QmWy2xNCp5hUrCygR dCBoxrKjfQI+w== Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id 9E4CDF40075; Wed, 3 Jun 2026 04:58:10 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-01.internal (MEProxy); Wed, 03 Jun 2026 04:58:10 -0400 X-ME-Sender: X-ME-Proxy-Cause: dmFkZTGr2weDGKBa0sUCUcj036iLL5Y1yiuWXtlNLmEI4O4KffGEG7mKCI4rtXP1Kjy/sC Vn4JLRDUw3n/LlH/P7ldcJy2f2NLMW7zEwQdl58eFGDw13Gd7uBwZtBFefeubqM57vT7KW gxI5DHTPlMa9V7t7GBAVKnyC4disspoUcyOJuYcuXeoXUDa8M5AS9XNNfwK+hXW4k6RRKP P+HnepDfV9Ly2SCGeboQtn62xJxY4OofV3op27GBS756vLSUraZsZIubTiRwHvbO7GWFg8 TN89ZhNEjfm9JCDm1LdV/dDNhv9gsSNYWX/LbCMQhfYJTNEbDdYGKUoqZbehxmbuTXbkFU XnaKhsn2lQq7XiJ+YTNPtHlw97iNDWbeNZirflpUY26TpW4YlC0yGx1F2Pdjov4xxyaUZd nGZuSrO0ofec6SMf5X9bTikzbc7jU39nUFa8+EDOEs+sLMDgAb7Jfbkdo1r3Pi14q8HECl WOyAkHMSoapVwjPlMra4gfnE/Sq1KO70VhXXH61epQ6Rh+aRLmPHQfsv+x4lMOk7iiwpsY 2Ln1UDislceGN/Gw4GkBXiCXnvOln8phYiq7SJoKkYgBG145jAMq3GJUgudNXhcY+kY+fP qpGcyL1cKdvM1YoB3pTqsi5xKVO8SJQEPQQW/+ABFCEXztbk2H+BY/x90g+g X-ME-Proxy: Feedback-ID: ice86485a:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 77D33182007A; Wed, 3 Jun 2026 04:58:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 Date: Wed, 03 Jun 2026 10:57:49 +0200 From: "Ard Biesheuvel" To: "Will Deacon" , linux-arm-kernel@lists.infradead.org, "Ard Biesheuvel" Cc: "Catalin Marinas" , kernel-team@android.com, linux-kernel@vger.kernel.org, "Mark Rutland" , "Ryan Roberts" , "Anshuman Khandual" , "Kevin Brodsky" , "Liz Prucka" , "Seth Jenkins" , "Kees Cook" , "Mike Rapoport" , "David Hildenbrand" , "Andrew Morton" , "Jann Horn" , linux-mm@kvack.org, linux-hardening@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, maz@kernel.org Message-Id: <2c7929d4-6622-475d-af1b-bcd0cd997cd3@app.fastmail.com> In-Reply-To: <178041415770.4024555.11336437584927054639.b4-ty@kernel.org> References: <20260529150150.1670604-17-ardb+git@google.com> <178041415770.4024555.11336437584927054639.b4-ty@kernel.org> Subject: Re: [PATCH v7 00/15] arm64: Unmap linear alias of kernel data/bss Content-Type: text/plain Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260603_015814_562191_09906314 X-CRM114-Status: GOOD ( 19.87 ) 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 (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 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 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))