[PATCH v2 4/4] arm64: Add support of PAuth QARMA3 architected algorithm

[Will Deacon]

On Mon, Feb 21, 2022 at 02:47:02PM +0000, Vladimir Murzin wrote:
> On 2/15/22 6:21 PM, Will Deacon wrote:
> > On Mon, Jan 31, 2022 at 05:06:54PM +0000, Vladimir Murzin wrote:
> >> QARMA3 is relaxed version of the QARMA5 algorithm which expected to
> >> reduce the latency of calculation while still delivering a suitable
> >> level of security.
> >>
> >> Support for QARMA3 can be discovered via ID_AA64ISAR2_EL1
> >>
> >>     APA3, bits [15:12] Indicates whether the QARMA3 algorithm is
> >>                        implemented in the PE for address
> >>                        authentication in AArch64 state.
> >>
> >>     GPA3, bits [11:8] Indicates whether the QARMA3 algorithm is
> >>                        implemented in the PE for generic code
> >>                        authentication in AArch64 state.
> >>
> >> Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
> >> ---

[...]

> >> @@ -596,6 +600,7 @@ static const struct arm64_ftr_bits ftr_raz[] = {
> >>  struct arm64_ftr_override __ro_after_init id_aa64mmfr1_override;
> >>  struct arm64_ftr_override __ro_after_init id_aa64pfr1_override;
> >>  struct arm64_ftr_override __ro_after_init id_aa64isar1_override;
> >> +struct arm64_ftr_override __ro_after_init id_aa64isar2_override;
> >>  
> >>  static const struct __ftr_reg_entry {
> >>  	u32			sys_id;
> >> @@ -644,6 +649,8 @@ static const struct __ftr_reg_entry {
> >>  	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64ISAR1_EL1, ftr_id_aa64isar1,
> >>  			       &id_aa64isar1_override),
> >>  	ARM64_FTR_REG(SYS_ID_AA64ISAR2_EL1, ftr_id_aa64isar2),
> >> +	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64ISAR2_EL1, ftr_id_aa64isar2,
> >> +			       &id_aa64isar2_override),
> >>  
> >>  	/* Op1 = 0, CRn = 0, CRm = 7 */
> >>  	ARM64_FTR_REG(SYS_ID_AA64MMFR0_EL1, ftr_id_aa64mmfr0),
> >> @@ -1834,10 +1841,11 @@ static bool has_address_auth_metacap(const struct arm64_cpu_capabilities *entry,
> >>  {
> >>  	bool api = has_address_auth_cpucap(cpu_hwcaps_ptrs[ARM64_HAS_ADDRESS_AUTH_IMP_DEF], scope);
> >>  	bool apa = has_address_auth_cpucap(cpu_hwcaps_ptrs[ARM64_HAS_ADDRESS_AUTH_ARCH_QARMA5], scope);
> >> +	bool apa3 = has_address_auth_cpucap(cpu_hwcaps_ptrs[ARM64_HAS_ADDRESS_AUTH_ARCH_QARMA3], scope);
> >>  
> >> -	WARN_ON(apa && api);
> >> +	WARN_ON((apa && api) || (apa && apa3) || (api && apa3));
> > 
> > I don't really get the point in this warning, what is somebody supposed to
> > do if they hit it? The kernel isn't the right place to make assertions about
> > the CPU design.
> 
> Right, there is nothing user can do other than reporting about that. It was
> inspired by the similar check in cpu_has_fwb(), yet I was under impression
> that assertion can be triggered via id regester override as well - now I see
> that invalid override is ignored.  I'm fine with removing assertion as long
> as code base use assertions consistently...

Yes, please send a version with these WARN_ON()s and I can queue it up.

Cheers,

Will