lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 20 Nov 2020 10:13:24 +0000
From:   Mark Rutland <>
To:     Vladimir Murzin <>
Cc:     Marc Zyngier <>,
        Neeraj Upadhyay <>,,,
        MSM <>,
        lkml <>,,
        Will Deacon <>,,
Subject: Re: AMU extension v1 support for cortex A76, A77, A78 CPUs

On Fri, Nov 20, 2020 at 09:09:00AM +0000, Vladimir Murzin wrote:
> On 11/20/20 8:56 AM, Marc Zyngier wrote:
> > On 2020-11-20 04:30, Neeraj Upadhyay wrote:
> >> Hi,
> >>
> >> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
> >> AA64PFR0[47:44] field is not set, and AMU does not get enabled for
> >> them.
> >> Can you please provide support for these CPUs in cpufeature.c?
> > 
> > If that was the case, that'd be an erratum, and it would need to be
> > documented as such. It could also be that this is an optional feature
> > for these cores (though the TRM doesn't suggest that).
> > 
> > Can someone at ARM confirm what is the expected behaviour of these CPUs?
> Not a confirmation, but IIRC, these are imp def features, while our cpufeatures
> catches architected one.

We generally don't make use of IMP-DEF featurees because of all the pain
it brings. 

Looking at the Cortex-A76 TRM, the encoding for AMCNTENCLR is:

 Op0: 3  (0b11)
 Op1: 3  (0b011)
 CRn: 15 (0b1111)
 CRm: 9  (0b1001)
 Op2: 7  (0b111)

... whereas the architected encoding (from our sysreg.h) is:

 Op0: 3
 Op1: 3
 CRn: 13
 CRm: 2
 Op2: 4

... so that's a different register with the same name, which is
confusing and unfortunate.

The encodings are different (and I haven't checked whether the fields /
semantics are the same), so it's not just a matter of wiring up new
detection code. There are also IMP-DEF traps in ACTLR_EL3 and ACTLR_EL2
which we can't be certain of the configuration of, and as the registers
are in the IMP-DEF encoding space they'll be trapped by HCR_EL2.TIDCP
and emulated as UNDEFINED by a hypervisor. All of that means that going
by the MIDR alone is not sufficient to know we can safely access the

So as usual for IMP-DEF stuff I don't think we can or should make use of


Powered by blists - more mailing lists