[PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[Marek Vasut]

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@mailbox.org>
---
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Yicong Yang <yangyicong@hisilicon.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@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
 
 alternative_if ARM64_HAS_RAS_EXTN
 	msr_s	SYS_DISR_EL1, xzr
@@ -470,7 +472,9 @@ SYM_FUNC_START(__cpu_setup)
 	mov	x1, MDSCR_EL1_TDCC		// Reset mdscr_el1 and disable
 	msr	mdscr_el1, x1			// access to the DCC from EL0
 	reset_pmuserenr_el0 x1			// Disable PMU access from EL0
+alternative_if ARM64_HAS_AMU_EXTN
 	reset_amuserenr_el0 x1			// Disable AMU access from EL0
+alternative_else_nop_endif
 
 	/*
 	 * Default values for VMSA control registers. These will be adjusted
-- 
2.51.0

Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[Marc Zyngier]

On Wed, 22 Oct 2025 14:35:28 +0100,
Marek Vasut <marek.vasut+renesas@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@mailbox.org>
> ---
> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Ryan Roberts <ryan.roberts@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Yicong Yang <yangyicong@hisilicon.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-renesas-soc@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?

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[Marek Vasut]

On 10/22/25 4:20 PM, Marc Zyngier wrote:
> On Wed, 22 Oct 2025 14:35:28 +0100,
> Marek Vasut <marek.vasut+renesas@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@mailbox.org>
>> ---
>> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>> Cc: Marc Zyngier <maz@kernel.org>
>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Yicong Yang <yangyicong@hisilicon.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-renesas-soc@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.

Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[Marc Zyngier]

On Wed, 22 Oct 2025 15:33:38 +0100,
Marek Vasut <marek.vasut@mailbox.org> 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@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@mailbox.org>
> >> ---
> >> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
> >> Cc: Catalin Marinas <catalin.marinas@arm.com>
> >> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> >> Cc: Marc Zyngier <maz@kernel.org>
> >> Cc: Ryan Roberts <ryan.roberts@arm.com>
> >> Cc: Will Deacon <will@kernel.org>
> >> Cc: Yicong Yang <yangyicong@hisilicon.com>
> >> Cc: linux-arm-kernel@lists.infradead.org
> >> Cc: linux-renesas-soc@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.

Well, I would tend to say that you are trying to update the wrong
piece of SW here. Crashing kernels should be a good incentive for the
board manufacturer to update their firmware pronto, specially when we
are talking of code that has been in the tree for over 5 years...

> 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.

But that doesn't really fix anything if you have a buggy firmware,
because you can't tell which CPUs have been correctly configured, and
which have not. I also don't really get why this hack works for you,
because the feature will be set as soon as one CPU advertises the
feature.

In any case, this sort of terminally broken stuff should be handled as
an IDreg override, for which we have a whole infrastructure already.
There are countless examples in the tree already for similar purposes.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[Catalin Marinas]

On Wed, Oct 22, 2025 at 04:02:15PM +0100, Marc Zyngier wrote:
> On Wed, 22 Oct 2025 15:33:38 +0100,
> Marek Vasut <marek.vasut@mailbox.org> 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@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@mailbox.org>
> > >> ---
> > >> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
> > >> Cc: Catalin Marinas <catalin.marinas@arm.com>
> > >> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> > >> Cc: Marc Zyngier <maz@kernel.org>
> > >> Cc: Ryan Roberts <ryan.roberts@arm.com>
> > >> Cc: Will Deacon <will@kernel.org>
> > >> Cc: Yicong Yang <yangyicong@hisilicon.com>
> > >> Cc: linux-arm-kernel@lists.infradead.org
> > >> Cc: linux-renesas-soc@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.
> 
> Well, I would tend to say that you are trying to update the wrong
> piece of SW here. Crashing kernels should be a good incentive for the
> board manufacturer to update their firmware pronto, specially when we
> are talking of code that has been in the tree for over 5 years...

I agree.

> > 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.
> 
> But that doesn't really fix anything if you have a buggy firmware,
> because you can't tell which CPUs have been correctly configured, and
> which have not. I also don't really get why this hack works for you,
> because the feature will be set as soon as one CPU advertises the
> feature.

I think Marek also disables the config option and the feature won't be
turned on.

-- 
Catalin

Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[Marek Vasut]

On 10/22/25 5:19 PM, Catalin Marinas wrote:

Hello Catalin,

>>>> 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.
>>
>> Well, I would tend to say that you are trying to update the wrong
>> piece of SW here. Crashing kernels should be a good incentive for the
>> board manufacturer to update their firmware pronto, specially when we
>> are talking of code that has been in the tree for over 5 years...
> 
> I agree.
> 
>>> 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.
>>
>> But that doesn't really fix anything if you have a buggy firmware,
>> because you can't tell which CPUs have been correctly configured, and
>> which have not. I also don't really get why this hack works for you,
>> because the feature will be set as soon as one CPU advertises the
>> feature.
> 
> I think Marek also disables the config option and the feature won't be
> turned on.

Correct.

-- 
Best regards,
Marek Vasut

Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[Marek Vasut]

On 10/22/25 5:02 PM, Marc Zyngier wrote:

Hello Marc,

>>> 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.
> 
> Well, I would tend to say that you are trying to update the wrong
> piece of SW here. Crashing kernels should be a good incentive for the
> board manufacturer to update their firmware pronto, specially when we
> are talking of code that has been in the tree for over 5 years...

I do agree with this, and the update already exists. The upstream TFA MR 
for this platform also has this fixed.

>> 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.
> 
> But that doesn't really fix anything if you have a buggy firmware,
> because you can't tell which CPUs have been correctly configured, and
> which have not.

I also agree.

> I also don't really get why this hack works for you,
> because the feature will be set as soon as one CPU advertises the
> feature.

For this old firmware, during development, ARM64_HAS_AMU_EXTN is 
disabled in kernel config to avoid triggering the AMU faults.

Except right now, I still trigger the AMU faults even with 
ARM64_HAS_AMU_EXTN=n , which I think should not happen ?

> In any case, this sort of terminally broken stuff should be handled as
> an IDreg override, for which we have a whole infrastructure already.
> There are countless examples in the tree already for similar purposes.

I would much rather not support the old firmware for this new platform 
in upstream and pollute the kernel with unnecessary workarounds.

I would much rather be able to disable ARM64_HAS_AMU_EXTN in kernel 
config for the old devices with old firmware, without triggering the 
faults ... and say that everything which is going to be upstream will 
always use new firmware that has proper working AMU support.

-- 
Best regards,
Marek Vasut

Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[Marc Zyngier]

On Wed, 22 Oct 2025 16:29:55 +0100,
Marek Vasut <marek.vasut@mailbox.org> wrote:
> 
> On 10/22/25 5:02 PM, Marc Zyngier wrote:
> 
> Hello Marc,
> 
> >>> 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.
> > 
> > Well, I would tend to say that you are trying to update the wrong
> > piece of SW here. Crashing kernels should be a good incentive for the
> > board manufacturer to update their firmware pronto, specially when we
> > are talking of code that has been in the tree for over 5 years...
> 
> I do agree with this, and the update already exists. The upstream TFA
> MR for this platform also has this fixed.
> 
> >> 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.
> > 
> > But that doesn't really fix anything if you have a buggy firmware,
> > because you can't tell which CPUs have been correctly configured, and
> > which have not.
> 
> I also agree.
> 
> > I also don't really get why this hack works for you,
> > because the feature will be set as soon as one CPU advertises the
> > feature.
> 
> For this old firmware, during development, ARM64_HAS_AMU_EXTN is
> disabled in kernel config to avoid triggering the AMU faults.
> 
> Except right now, I still trigger the AMU faults even with
> ARM64_HAS_AMU_EXTN=n , which I think should not happen ?

ARM64_HAS_AMU_EXTN is a *capability*, not a configuration.
CONFIG_ARM64_AMU_EXTN is the configuration. I have the feeling you're
mixing the two.

Irrespective of the configuration, we access the AMU registers
depending on the what is advertised, because we *must* make these
registers inaccessible from EL0, no matter what.

> > In any case, this sort of terminally broken stuff should be handled as
> > an IDreg override, for which we have a whole infrastructure already.
> > There are countless examples in the tree already for similar purposes.
> 
> I would much rather not support the old firmware for this new platform
> in upstream and pollute the kernel with unnecessary workarounds.
>
> I would much rather be able to disable ARM64_HAS_AMU_EXTN in kernel
> config for the old devices with old firmware, without triggering the
> faults ... and say that everything which is going to be upstream will
> always use new firmware that has proper working AMU support.

No, that's the wrong approach. If you leave the AMU accessible to EL0,
you're leaking data to userspace, and that's pretty wrong, no matter
how you look at it.

I also think your hack works by pure luck, because at the point where
your CPUs are booting, the alternatives are yet not in place (the
kernel patching happens much later). In short, this breaks
*everything*.

As I indicated before, you have two options:

- either you update your firmware and leave the kernel alone

- or you implement the workaround as ID register override so that you
  *must* pass something on the kernel command line to boot, and by
  then accept that you will leak critical timing information to
  userspace.

Any other option, including guarding the macro with a config option is
*not* acceptable.

Thanks,

	M.

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

Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[Marek Vasut]

On 10/23/25 4:19 PM, Marc Zyngier wrote:

Hello Marc,

>> Except right now, I still trigger the AMU faults even with
>> ARM64_HAS_AMU_EXTN=n , which I think should not happen ?
> 
> ARM64_HAS_AMU_EXTN is a *capability*, not a configuration.
> CONFIG_ARM64_AMU_EXTN is the configuration. I have the feeling you're
> mixing the two.
> 
> Irrespective of the configuration, we access the AMU registers
> depending on the what is advertised, because we *must* make these
> registers inaccessible from EL0, no matter what.

Ahhh, I was missing this part, thank you for clarifying.

>> I would much rather be able to disable ARM64_HAS_AMU_EXTN in kernel
>> config for the old devices with old firmware, without triggering the
>> faults ... and say that everything which is going to be upstream will
>> always use new firmware that has proper working AMU support.
> 
> No, that's the wrong approach. If you leave the AMU accessible to EL0,
> you're leaking data to userspace, and that's pretty wrong, no matter
> how you look at it.
> 
> I also think your hack works by pure luck, because at the point where
> your CPUs are booting, the alternatives are yet not in place (the
> kernel patching happens much later). In short, this breaks
> *everything*.
> 
> As I indicated before, you have two options:
> 
> - either you update your firmware and leave the kernel alone
> 
> - or you implement the workaround as ID register override so that you
>    *must* pass something on the kernel command line to boot, and by
>    then accept that you will leak critical timing information to
>    userspace.
> 
> Any other option, including guarding the macro with a config option is
> *not* acceptable.

Since I am getting an exception when I access the AMU register, would it 
be possible to trap that exception, and report something to the user 
instead of outright crashing with no output ?

Similar to what Linux already does on the various speculative execution 
bugs on x86, something like this?

"
MDS CPU bug present and SMT on, data leak possible. See 
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for 
more details.
"

-- 
Best regards,
Marek Vasut

Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[Marc Zyngier]

On Thu, 23 Oct 2025 16:58:49 +0100,
Marek Vasut <marek.vasut@mailbox.org> wrote:
> 
> On 10/23/25 4:19 PM, Marc Zyngier wrote:
> 
> Hello Marc,
> 
> >> Except right now, I still trigger the AMU faults even with
> >> ARM64_HAS_AMU_EXTN=n , which I think should not happen ?
> > 
> > ARM64_HAS_AMU_EXTN is a *capability*, not a configuration.
> > CONFIG_ARM64_AMU_EXTN is the configuration. I have the feeling you're
> > mixing the two.
> > 
> > Irrespective of the configuration, we access the AMU registers
> > depending on the what is advertised, because we *must* make these
> > registers inaccessible from EL0, no matter what.
> 
> Ahhh, I was missing this part, thank you for clarifying.
> 
> >> I would much rather be able to disable ARM64_HAS_AMU_EXTN in kernel
> >> config for the old devices with old firmware, without triggering the
> >> faults ... and say that everything which is going to be upstream will
> >> always use new firmware that has proper working AMU support.
> > 
> > No, that's the wrong approach. If you leave the AMU accessible to EL0,
> > you're leaking data to userspace, and that's pretty wrong, no matter
> > how you look at it.
> > 
> > I also think your hack works by pure luck, because at the point where
> > your CPUs are booting, the alternatives are yet not in place (the
> > kernel patching happens much later). In short, this breaks
> > *everything*.
> > 
> > As I indicated before, you have two options:
> > 
> > - either you update your firmware and leave the kernel alone
> > 
> > - or you implement the workaround as ID register override so that you
> >    *must* pass something on the kernel command line to boot, and by
> >    then accept that you will leak critical timing information to
> >    userspace.
> > 
> > Any other option, including guarding the macro with a config option is
> > *not* acceptable.
> 
> Since I am getting an exception when I access the AMU register, would
> it be possible to trap that exception, and report something to the
> user instead of outright crashing with no output ?

The trap exists, and the exception is being routed to EL3. There is
nothing you can do about that if running at EL2, and if at EL1, you'd
need to take the trap to EL2 to handle it. And if you can do that,
what do you do?  Not doing anything is wrong, and doing something will
nuke your machine.

> Similar to what Linux already does on the various speculative
> execution bugs on x86, something like this?
> 
> "
> MDS CPU bug present and SMT on, data leak possible. See
> https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html
> for more details.
> "

You're completely off base. The problem at hand has nothing to do with
speculation, and everything to do with access permission to counter
registers.

I also wouldn't be surprised if you could take your whole machine down
from userspace just by ticking some of the AM*_EL0 registers (the
pseudocode clearly shows that there is a route to EL3 in this case).

Honestly, I think you should stop trying to papering over this issue
behind the user's back. If you want this addressed, do it so that the
user knows their machine is fsck'd, and that they are OK with that. Do
it by implementing an ID register override that requires a kernel
command-line argument.

Do I sound like a stuck record? Probably. But that's IMO the only
acceptable solution for what you have. I'm looking forward to
reviewing a patch implementing that suggestion, but I'll stop even
thinking of how to paper over this in the way you suggest.

Thanks,

	M.

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

Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[Marek Vasut]

On 10/24/25 11:27 AM, Marc Zyngier wrote:

Hello again,

>> Similar to what Linux already does on the various speculative
>> execution bugs on x86, something like this?
>>
>> "
>> MDS CPU bug present and SMT on, data leak possible. See
>> https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html
>> for more details.
>> "
> 
> You're completely off base. The problem at hand has nothing to do with
> speculation, and everything to do with access permission to counter
> registers.
> 
> I also wouldn't be surprised if you could take your whole machine down
> from userspace just by ticking some of the AM*_EL0 registers (the
> pseudocode clearly shows that there is a route to EL3 in this case).
> 
> Honestly, I think you should stop trying to papering over this issue
> behind the user's back. If you want this addressed, do it so that the
> user knows their machine is fsck'd, and that they are OK with that. Do
> it by implementing an ID register override that requires a kernel
> command-line argument.
> 
> Do I sound like a stuck record? Probably. But that's IMO the only
> acceptable solution for what you have. I'm looking forward to
> reviewing a patch implementing that suggestion, but I'll stop even
> thinking of how to paper over this in the way you suggest.
Just to wrap this one up. TFA master shortly after 2.14 release now 
contains X5H support with fixed AMU enablement, so this AMU access issue 
is gone. I think this thread can be closed.

Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[Yicong Yang]

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@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@mailbox.org>
>>> ---
>>> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>>> Cc: Marc Zyngier <maz@kernel.org>
>>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>>> Cc: Will Deacon <will@kernel.org>
>>> Cc: Yicong Yang <yangyicong@hisilicon.com>
>>> Cc: linux-arm-kernel@lists.infradead.org
>>> Cc: linux-renesas-soc@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.

move the guard into reset_amuserenr_el0 macro will be neater here (personally I think).

thanks.

Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[Marek Vasut]

On 10/23/25 2:01 PM, Yicong Yang wrote:

Hello Yicong,

>> 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.
> 
> move the guard into reset_amuserenr_el0 macro will be neater here (personally I think).

I can update the patch this way, sure.

If this is also OK with ARM people, I can send a V2 like that ?

-- 
Best regards,
Marek Vasut

Re: [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@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@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@mailbox.org>
> >>> ---
> >>> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
> >>> Cc: Catalin Marinas <catalin.marinas@arm.com>
> >>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> >>> Cc: Marc Zyngier <maz@kernel.org>
> >>> Cc: Ryan Roberts <ryan.roberts@arm.com>
> >>> Cc: Will Deacon <will@kernel.org>
> >>> Cc: Yicong Yang <yangyicong@hisilicon.com>
> >>> Cc: linux-arm-kernel@lists.infradead.org
> >>> Cc: linux-renesas-soc@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.

Re: [PATCH] arm64: guard AMU register access with ARM64_HAS_AMU_EXTN

[Yicong Yang]

On 2025/10/23 22:21, Marc Zyngier wrote:
> On Thu, 23 Oct 2025 13:01:52 +0100,
> Yicong Yang <yangyccccc@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@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@mailbox.org>
>>>>> ---
>>>>> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
>>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>> Cc: Marc Zyngier <maz@kernel.org>
>>>>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>>>>> Cc: Will Deacon <will@kernel.org>
>>>>> Cc: Yicong Yang <yangyicong@hisilicon.com>
>>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>>> Cc: linux-renesas-soc@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.
ok got it. so this is a security concern to ensure EL0 access is disabled on AMU supported
hardware even if the kernel support is not compiled in. thanks for the explanation.

thanks.