From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F06A5224AF2 for ; Mon, 22 Jun 2026 16:43:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782146591; cv=none; b=H18i8F0MHCni7sU4lenz8OTkxiqgosvmIDhakmzHmk3x7LK26vZjbvz/0jIXhInirAP1mgdvSUKLk8Wbgf8IvUT6t91VCRmBH8PK1jHWZNEYQnC+8oU2Dm9Iw2c9kdnJpYx7K4Ke2vYVuO4Uviezuo0csPWdoVYo2Avb6b0fQ/4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782146591; c=relaxed/simple; bh=PN7wogKQxLF7VClh2nnnslFM/kkLG8IOHcqvhbrXuxI=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=C0HcLkLvxdaF6HsW7iG+Elbs+YMXgDLkoVwKNF+J2KVfQAFznJLTMPQNZ2VLEYWThFUadv7hpMvPlu7DXpLlJpUPgEqbxgF0N3CYQH0QvB/QcHtrgpf3OH/c5ryVai3EtLXTS4wD7EMa60c7a6sCqnGum99DLSavkCkVYdAGq/I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XtYEXhAH; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XtYEXhAH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49F381F00A3D; Mon, 22 Jun 2026 16:43:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782146589; bh=PN7wogKQxLF7VClh2nnnslFM/kkLG8IOHcqvhbrXuxI=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=XtYEXhAHPT62soHNZM2g8T7mB2yrj2DmxihkUmAQbIOL7H3WL0cQaFfXPeiByjsgW JuYgYrqr5dM1JAZqxj0K42ik4COfXEw4l7wQlT5h4FVAwfsmadHEEB1xhbjq1eKtly ZYQssIq5NDEPngOIs9i+tv4cztesNwaq7uHN2QecevMnWGD5+yvTfmhyDn/VJ+hejp nhkCMNGW68m60jjmC7JfHGvn9rzq+syBKZGE3EfuKeTRwKBtlDiJ202daRsSvsN/h+ eg3gqSXLSJ71iiYDY/m4jzdQSeK2WyO/I19NK0XFiCrz87pm3XhvxlWmfWaPjljgVd NoSeUDfY72Wiw== Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id 8459DF40084; Mon, 22 Jun 2026 12:43:08 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-01.internal (MEProxy); Mon, 22 Jun 2026 12:43:08 -0400 X-ME-Sender: X-ME-Proxy-Cause: dmFkZTF53aT3vr3RJy0/mjtaR2SAmkMkVdvRezRGlzFgDlqFwrn7fonUnhXEXC0uJoMmLO H746fRtP0UdFgOA5W8EsygTmCyiaEi3cNN00KXXDF3c1d8jlrI7ZFO3eV7qy6Rb3GKEgpP 0ibskE58I4dwqJgvZ+NkLdM1+XvCWcxu7no4Wxtd+nTmEiTI+gw7iRnZH2ymxkIA//JJKh CZAHK7wSUuFaYn5p2t0FTJgczuDWz7fHP3+EYr5edR8wwfshgtVQI8VjjMwhsuNm3Gb3oP nEEDLMaoMG+rSe+0ITIiAHozUvyws9kyYVjdWXyZ7/XtgFD7xV4Kpom+babNSUVv1AxPnJ mevKTrdFShKAIdUNnaCQrvwg3tQcXqtsOjXPRJ740BvK+gL1OjuiXpI4IWytbpqPPknqYE Qf8EIig2O3m+qd/RjuTZuF/0nldUXZZwZDMRheXZCMAC9bsQ28DON6BBBcUBE9mwrF+cBo 83oh4Ci0gLcb3Dp5nfJ/ucuyNJKfn5m8XAanmp8pyO8241rD294LDWFRvMuj251nD6/2j4 5qPBaFxnT/0OFhrUUw3P9BOJkxtdziGRx2Yk1Sj9zi4d8/eg4wMVaDOD201QDhQFKmWGFZ FQKWcphStjTZ1qep4iQCyHZkmZ4lGFcw1jAKI7iAtO+pGNc3TE4XklcBvQEA X-ME-Proxy: Feedback-ID: ice86485a:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 61F69182008C; Mon, 22 Jun 2026 12:43:08 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Mon, 22 Jun 2026 18:42:46 +0200 From: "Ard Biesheuvel" To: "Kevin Brodsky" , "Ard Biesheuvel" , linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org, "Catalin Marinas" , "Will Deacon" , "Fuad Tabba" Message-Id: <2d27eaa8-3324-48b3-97b0-aecf63639c18@app.fastmail.com> In-Reply-To: <2deff570-0497-4438-94ba-a9691881a016@arm.com> References: <20260619163940.3185308-2-ardb+git@google.com> <2deff570-0497-4438-94ba-a9691881a016@arm.com> Subject: Re: [PATCH] arm64: mm: Defer read-only remap of data/bss linear alias Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kevin, On Mon, Jun 22, 2026 at 5:23=E2=80=AFPM Kevin Brodsky wrote: > > On 19/06/2026 18:39, Ard Biesheuvel wrote: > > From: Ard Biesheuvel > > > > Fuad reports that in some cases, the KVM init code may apply relocat= ions > > to variables that reside in .data, and does so via the linear map. T= his > > means that remapping .data read-only beforehand is a bad idea, and > > results in an early boot crash. > > > > These variables in .data are only present when CONFIG_NVHE_EL2_DEBUG= or > > CONFIG_NVHE_EL2_TRACING are enabled, which is why it was not spotted= in > > testing. > > > > So move the remap to mark_rodata_ro(), which is a reasonable place to > > put this, and ensures that it happens much later during the boot. It > > also means that rodata=3Doff is now taken into account, and so the l= inear > > alias will remain writable in that case. > > > > Cc: Fuad Tabba > > Fixes: f2ba877402e5 ("arm64: mm: Map the kernel data/bss read-only i= n the linear map") > > Signed-off-by: Ard Biesheuvel > > --- > > =C2=A0arch/arm64/mm/mmu.c | 11 ++++++----- > > =C2=A01 file changed, 6 insertions(+), 5 deletions(-) > > > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > > index 9f354971b7e4..1f7eca86b5c1 100644 > > --- a/arch/arm64/mm/mmu.c > > +++ b/arch/arm64/mm/mmu.c > > @@ -1198,11 +1198,6 @@ static void __init map_mem(void) > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 __map_memblock(star= t, end, pgprot_tagged(PAGE_KERNEL), > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0flags); > > =C2=A0 =C2=A0 =C2=A0 } > > - > > - =C2=A0 =C2=A0 /* Map the kernel data/bss read-only in the linear m= ap */ > > - =C2=A0 =C2=A0 __map_memblock(init_end, kernel_end, PAGE_KERNEL_RO,= flags); > > - =C2=A0 =C2=A0 flush_tlb_kernel_range((unsigned long)lm_alias(__ini= t_end), > > - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(unsigned long)lm_alias(__bss_stop)); > > =C2=A0} > >=20 > > =C2=A0void mark_rodata_ro(void) > > @@ -1221,6 +1216,12 @@ void mark_rodata_ro(void) > > =C2=A0 =C2=A0 =C2=A0 update_mapping_prot(__pa_symbol(_text), (unsign= ed long)_text, > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 (unsigned long)_stext - (unsigned long)_text, > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 PAGE_KERNEL_RO); > > + > > + =C2=A0 =C2=A0 /* Map the kernel data/bss read-only in the linear m= ap */ > > + =C2=A0 =C2=A0 update_mapping_prot(__pa_symbol(__init_end), > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 (unsigned long)lm_alias(__init_end), > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 (unsigned long)__bss_stop - (unsigned long)__init_end, > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 PAGE_KERNEL_RO); > > I was rather confused by this patch until I saw in master: > > f102131c842d Revert "arm64: mm: Unmap kernel data/bss entirely from the > linear map" > 81479b6888f8 Revert "arm64: mm: Defer remap of linear alias of data/bs= s" > > ... which explains the diff, but it looks like there are multiple issu= es > here. Is my understanding correct that these reverts fix kvm_arm_init() > because it needs to *read* from the linear map, while this new patch > fixes some KVM configurations that need to *write* to the linear map? > Basically, yes. > If so it might be good to give a recap in the commit message, because > the reverts are easy to miss. > Ok > It would also be good to explain why we can't do this in > mark_linear_text_alias_ro() (presumably because this is too early). I = do > agree that honouring rodata=3Doff is a good thing, though. > I didn't consider that tbh - I'll check whether that is a more suitable location. But generally, I think doing it later rather than earlier is fine because it reduces the likelihood of hidden issues such as the one being addressed by this patch, and I don't think doing this very early makes a meaningful difference in terms of robustness. > BTW, if only kvm_arm_init() needs to read the data/bss via the linear > map, maybe we can still unmap it later? > Yes, it is still my intent to bring back the patches that unmap this ali= as entirely, including some additional tweaks for the fixmap PTE level table that I dropped after an earlier revision. But that will be 7.3 material, whereas this fixes a regression due to the changes that were pulled for = 7.2. =C2=A0