[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