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

[Vladimir Murzin]

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 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.
                            ^^^^^^
Sorry, Will, did you mean *without*?

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

Cheers
Vladimir


> 
> Cheers,
> 
> Will
>