[v2,0/2] ARM/arm64: errata: Remove AES hwcap for 32bit tasks on A57/A72

Message

James Morse April 13, 2022, 5:05 p.m. UTC

Hello,

These patches remove the AES HWCAP on A57 and A72 for aarch32 user-space
processes due to erratum #1742098 and #1655431. An interrupt between two
instructions will cause these parts to get the wrong result.
These extensions are optional, so software should have a fallback
implementation.

The 32bit patch is new for v2, as Ard points out the behaviour should
be the same here.

Operating on the HWCAP bitmap directly avoids affecting KVM, which
was the problem with v1. But it does mean HWCAP_PMULL is still visible
to aarch32 processes. This isn't affected by the erratum, but is detected
from the same field in the ID register. PMULL is value '2', AES is value '1'.
User-space would be crazy to let PMULL imply AES, right ...

There is no dependency between the two patches.

[v1] https://lore.kernel.org/linux-arm-kernel/[e-mail]/
[A57] https://developer.arm.com/documentation/epm049219/2300  #1742098
[A72 https://developer.arm.com/documentation/epm012079/11     #1655431


Thanks,

James Morse (2):
  arm64: errata: Remove AES hwcap for COMPAT tasks
  ARM: Remove AES hwcap for parts affected by errata

 Documentation/arm64/silicon-errata.rst |  4 ++++
 arch/arm/kernel/setup.c                |  9 +++++++++
 arch/arm64/Kconfig                     | 16 ++++++++++++++++
 arch/arm64/kernel/cpu_errata.c         | 16 ++++++++++++++++
 arch/arm64/kernel/cpufeature.c         | 11 ++++++++++-
 arch/arm64/tools/cpucaps               |  1 +
 6 files changed, 56 insertions(+), 1 deletion(-)

Comments

Will Deacon April 20, 2022, 10:15 a.m. UTC | #1

On Wed, Apr 13, 2022 at 06:05:43PM +0100, James Morse wrote:
> Hello,
> 
> These patches remove the AES HWCAP on A57 and A72 for aarch32 user-space
> processes due to erratum #1742098 and #1655431. An interrupt between two
> instructions will cause these parts to get the wrong result.
> These extensions are optional, so software should have a fallback
> implementation.
> 
> The 32bit patch is new for v2, as Ard points out the behaviour should
> be the same here.
> 
> Operating on the HWCAP bitmap directly avoids affecting KVM, which
> was the problem with v1. But it does mean HWCAP_PMULL is still visible
> to aarch32 processes. This isn't affected by the erratum, but is detected
> from the same field in the ID register. PMULL is value '2', AES is value '1'.
> User-space would be crazy to let PMULL imply AES, right ...

That seems like a completely sensible thing for userspace to do :/

The Arm ARM states:


AES, bits [7:4]
Indicates support for AES instructions in AArch64 state. Defined values are:
0b0000 No AES instructions implemented.
0b0001 AESE, AESD, AESMC, and AESIMC instructions implemented.
0b0010 As for 0b0001 , plus PMULL/PMULL2 instructions operating on 64-bit data quantities.


So PMULL is defined to include AES.

Will