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

[Will Deacon <will@kernel.org>]

On Wed, Feb 23, 2022 at 11:20:40AM +0000, Vladimir Murzin wrote:
> On 2/22/22 9:50 PM, Will Deacon wrote:
> > 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@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.
>                             ^^^^^^
> Sorry, Will, did you mean *without*?

Urgh, yes, sorry about that.

> Do you want separate patch to remove WARN_ON from cpu_has_fwb() as well?

Yes, good thinking.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel