[PATCH] arm64: errata: Remove AES hwcap for COMPAT tasks on A57 and A72

[Catalin Marinas]

Hi James,

On Thu, Jan 27, 2022 at 12:29:14PM +0000, James Morse wrote:
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index 9e1c1aef9ebd..b06fb054e055 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -376,6 +376,14 @@ static struct midr_range trbe_write_out_of_range_cpus[] = {
>  };
>  #endif /* CONFIG_ARM64_WORKAROUND_TRBE_WRITE_OUT_OF_RANGE */
>  
> +#ifdef CONFIG_ARM64_ERRATUM_1742098
> +static struct midr_range broken_aarch32_aes[] = {
> +	MIDR_RANGE(MIDR_CORTEX_A57, 0, 1, 0xf, 0xf),
> +	MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
> +	{},
> +};
> +#endif /* CONFIG_ARM64_WORKAROUND_TRBE_WRITE_OUT_OF_RANGE */
> +
>  const struct arm64_cpu_capabilities arm64_errata[] = {
>  #ifdef CONFIG_ARM64_WORKAROUND_CLEAN_CACHE
>  	{
> @@ -597,6 +605,15 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
>  		.type = ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE,
>  		CAP_MIDR_RANGE_LIST(trbe_write_out_of_range_cpus),
>  	},
> +#endif
> +#ifdef CONFIG_ARM64_ERRATUM_1742098
> +	{
> +		.desc = "ARM erratum 1742098",
> +		.capability = ARM64_WORKAROUND_1742098,
> +		CAP_MIDR_RANGE_LIST(broken_aarch32_aes),
> +		.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
> +		.cpu_enable = arm64_remove_aes_compat_hwcap,
> +	},
>  #endif
>  	{
>  	}
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index a46ab3b1c4d5..06605e267ab0 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1900,6 +1900,29 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
>  }
>  #endif /* CONFIG_ARM64_MTE */
>  
> +#ifdef CONFIG_ARM64_ERRATUM_1742098
> +/*
> + * compat_elf_hwcap{,2} are built from the sanitised id registers after the
> + * enable calls have run.  See the order of the setup_system_capabilities()
> + * and setup_elf_hwcaps() calls in setup_cpu_features(). Removing the AES
> + * field prevents the AES hwcap from being advertised.
> + */
> +void arm64_remove_aes_compat_hwcap(const struct arm64_cpu_capabilities *cap)
> +{
> +	struct arm64_ftr_reg *aa32isar5 = get_arm64_ftr_reg(SYS_ID_ISAR5_EL1);
> +	u64 aes_mask = GENMASK_ULL(ID_ISAR5_AES_SHIFT + 3, ID_ISAR5_AES_SHIFT);
> +
> +	/*
> +	 * On affected platforms this call is made via stop_machine() on all
> +	 * online CPUs. Only clear the register from the boot CPU.
> +	 */
> +	if (smp_processor_id())
> +		return;
> +
> +	aa32isar5->sys_val &= ~aes_mask;
> +}
> +#endif /* CONFIG_ARM64_ERRATUM_1742098 */

I wonder whether this would look better if we use the
ARM64_FTR_REG_OVERRIDE approach with an id_isar5_override defined in
cpu_errata.c and populated there. I haven't checked the order in which
they would be called though.

Alternatively, we could make the ftr_id_isar5 reg global and patch it
directly in cpu_errata.c (arm64_ftr_reg_ctrel0 is another case where we
made it global). Yet another option would be to add some function in
cpufeature.[hc] to patch a feature directly and we'd call it from
cpu_errata.c. My preference would be to keep the cpu_enable function for
the workaround in cpu_errata.c.

Is this the first case where we need to change the ELF HWCAPs due to an
erratum?

-- 
Catalin