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 5ADFFCCD1BE for ; Thu, 23 Oct 2025 14:22:07 +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:MIME-Version:References:In-Reply-To:Subject:Cc:To:From: Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=VbZSHBIT5GhfdL6WxWwpO/dLxPxmanmATkd5CF4DeeI=; b=JDmMoytsponDxfZ7fDI5IZ6KD/ yBMyAJb2g4qXsdLEj0IjsTzy7FjA2y89Fy7iQTJoeR/mNq3nwIJC6ULIgmfFADkmDPVXCHUMU54Q1 joPpC+dQAsJZ34AgxaEfpjSWuwP/CYhZvRvIJfcpWb0EWOa3DGtYTwBzhiSSv1kMS3M8OJEfrO9de MI4Mo7Wfsb0ef7g4NJxcxdeFAOAUjLyfg9VKUSpKnUzWaIiLF5+yguQA+GirBfbQ2Uh0+ZKcM+5hO aVCBMtF9apYxo5gKVWOwJDR3iUh1DuvX53yYIcywKZPtGaeHltHGuqKCiYQ95zn5rmc7OqozbbzQ6 eh3EqxJA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vBwCX-00000006ZiW-3Itf; Thu, 23 Oct 2025 14:22:01 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vBwCV-00000006ZhL-1bEP for linux-arm-kernel@lists.infradead.org; Thu, 23 Oct 2025 14:22:00 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 687444AEB3; Thu, 23 Oct 2025 14:21:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 404DCC4CEE7; Thu, 23 Oct 2025 14:21:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1761229318; bh=Cg8X9zCcHh0XZYuwWRJDuEQoaZUgfI3iONaxAqyi2xk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=S428L3Bk8p7+d0dpiXGJxlLFK2FjustCMjwWbOZNUHA2EC6tF4PVZKrQ2hoJOYYI4 UqVS/AuFlK6GCdFnK1hTMIAWC0LnJ74usES2Y206HKYafzAiQFSHB4TJOKTV3sUBve O6vGcR1YGGHtEBz0Irw+VAp7g/FfFXmnQ/P5ScD8OA1pHfndffKxKj0MjiLm0jIafv hgCd3xJMqghAnXJFs86pb+B4gcQl1txnvEpkPsbwlbPdCdKnpDJBbwK+clK6nRlZHR /V1ahbx5T9XrhqDv2gpDhOD7JqL9NofvoHdYKuC079FGXhbC3eWd4d6HacAOSsSmfm kQwYSvSUjVoeA== Received: from 158.46.66.37.rev.sfr.net ([37.66.46.158] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vBwCR-0000000GYKV-3yGj; Thu, 23 Oct 2025 14:21:56 +0000 Date: Thu, 23 Oct 2025 15:21:55 +0100 Message-ID: <87wm4l3dh8.wl-maz@kernel.org> From: Marc Zyngier To: Yicong Yang Cc: Marek Vasut , Marek Vasut , linux-arm-kernel@lists.infradead.org, Anshuman Khandual , Catalin Marinas , Geert Uytterhoeven , Ryan Roberts , Will Deacon , Yicong Yang , linux-renesas-soc@vger.kernel.org Subject: Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN In-Reply-To: <632d6afe-40d3-4632-99c7-b098967bd649@gmail.com> References: <20251022133621.178546-1-marek.vasut+renesas@mailbox.org> <86347bvx0f.wl-maz@kernel.org> <07391913-aab6-4d92-b75f-278506f51397@mailbox.org> <632d6afe-40d3-4632-99c7-b098967bd649@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 37.66.46.158 X-SA-Exim-Rcpt-To: yangyccccc@gmail.com, marek.vasut@mailbox.org, marek.vasut+renesas@mailbox.org, linux-arm-kernel@lists.infradead.org, anshuman.khandual@arm.com, catalin.marinas@arm.com, geert+renesas@glider.be, ryan.roberts@arm.com, will@kernel.org, yangyicong@hisilicon.com, linux-renesas-soc@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251023_072159_476752_395D856A X-CRM114-Status: GOOD ( 30.17 ) 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 On Thu, 23 Oct 2025 13:01:52 +0100, Yicong Yang wrote: >=20 > On 2025/10/22 22:33, Marek Vasut wrote: > > On 10/22/25 4:20 PM, Marc Zyngier wrote: > >> On Wed, 22 Oct 2025 14:35:28 +0100, > >> Marek Vasut wrote: > >>> > >>> The AMU configuration register access may fault and prevent successful > >>> kernel boot. This can occur for example in case the firmware does not > >>> allow AMU counter access from EL1. Guard the AMU configuration regist= er > >>> access with ARM64_HAS_AMU_EXTN to prevent this fault if ARM64_HAS_AMU= _EXTN > >>> Kconfig option is explicitly disabled. Other interaction with the AMU= is > >>> already guarded by similar ifdeffery. > >>> > >>> Fixes: 87a1f063464a ("arm64: trap to EL1 accesses to AMU counters fro= m EL0") > >>> Signed-off-by: Marek Vasut > >>> --- > >>> Cc: Anshuman Khandual > >>> Cc: Catalin Marinas > >>> Cc: Geert Uytterhoeven > >>> Cc: Marc Zyngier > >>> Cc: Ryan Roberts > >>> Cc: Will Deacon > >>> Cc: Yicong Yang > >>> Cc: linux-arm-kernel@lists.infradead.org > >>> Cc: linux-renesas-soc@vger.kernel.org > >>> --- > >>> =C2=A0 arch/arm64/mm/proc.S | 4 ++++ > >>> =C2=A0 1 file changed, 4 insertions(+) > >>> > >>> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S > >>> index 86818511962b6..123538ffeda6b 100644 > >>> --- a/arch/arm64/mm/proc.S > >>> +++ b/arch/arm64/mm/proc.S > >>> @@ -145,7 +145,9 @@ SYM_FUNC_START(cpu_do_resume) > >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ubfx=C2=A0=C2=A0=C2=A0 x11, x11, #1, #1 > >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 msr=C2=A0=C2=A0=C2=A0 oslar_el1, x11 > >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reset_pmuserenr_el0 x0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // Disable PMU access f= rom EL0 > >>> +alternative_if ARM64_HAS_AMU_EXTN > >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reset_amuserenr_el0 x0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // Disable AMU access f= rom EL0 > >>> +alternative_else_nop_endif > >> > >> Why? > >> > >> We ensure that the AMU is available in the macro itself by checking > >> for ID_AA64PFR0_EL1.AMU. If the AMu isn't present on this CPU, we skip > >> the offending sysreg access. This is similar to what we do for the > >> PMU. > >> > >> Does your HW advertise an AMU, but doesn't actually have one? > > The hardware does have AMU, but it is currently blocked in old TFA vers= ion and access to this AMU register here causes a fault. That's why I have = to disable ARM64_HAS_AMU_EXTN until the TFA is updated and the AMU access i= s made available on this hardware. But even if I do disable ARM64_HAS_AMU_E= XTN=3Dn , I get a fault. > > > > This patch is mainly meant to prevent a surprise in case someone does s= et ARM64_HAS_AMU_EXTN=3Dn , and the system still faults on AMU register acc= ess. > > >=20 > then I think it's more proper to guard it with CONFIG_ARM64_AMU_EXTN > (I think you mean this above?) rathter than the cpu cap. then with > the patch kernel won't touch the AMU registers here if the kconfig > is disabled on you AMU supported hardware and AMU unsupported > firmware. No. Not preventing EL0 from accessing the register is a data leak to userspace. This must be acted upon irrespective of the kernel being AMU-enabled or not. M. --=20 Jazz isn't dead. It just smells funny.