[PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[Marc Zyngier]

On Thu, 23 Oct 2025 13:01:52 +0100,
Yicong Yang <yangyccccc at gmail.com> wrote:
> 
> 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 <marek.vasut+renesas at mailbox.org> 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 register
> >>> 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 from EL0")
> >>> Signed-off-by: Marek Vasut <marek.vasut+renesas at mailbox.org>
> >>> ---
> >>> Cc: Anshuman Khandual <anshuman.khandual at arm.com>
> >>> Cc: Catalin Marinas <catalin.marinas at arm.com>
> >>> Cc: Geert Uytterhoeven <geert+renesas at glider.be>
> >>> Cc: Marc Zyngier <maz at kernel.org>
> >>> Cc: Ryan Roberts <ryan.roberts at arm.com>
> >>> Cc: Will Deacon <will at kernel.org>
> >>> Cc: Yicong Yang <yangyicong at hisilicon.com>
> >>> Cc: linux-arm-kernel at lists.infradead.org
> >>> Cc: linux-renesas-soc at vger.kernel.org
> >>> ---
> >>>   arch/arm64/mm/proc.S | 4 ++++
> >>>   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)
> >>>       ubfx    x11, x11, #1, #1
> >>>       msr    oslar_el1, x11
> >>>       reset_pmuserenr_el0 x0            // Disable PMU access from EL0
> >>> +alternative_if ARM64_HAS_AMU_EXTN
> >>>       reset_amuserenr_el0 x0            // Disable AMU access from 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 version 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 is made available on this hardware. But even if I do disable ARM64_HAS_AMU_EXTN=n , I get a fault.
> >
> > This patch is mainly meant to prevent a surprise in case someone does set ARM64_HAS_AMU_EXTN=n , and the system still faults on AMU register access.
> >
> 
> 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.

-- 
Jazz isn't dead. It just smells funny.