[PATCH v2] ARM: advertise availability of v8 Crypto instructions

[Ard Biesheuvel]

On 9 March 2015 at 19:12, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 9 March 2015 at 19:06, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
>> On Thu, Mar 05, 2015 at 12:51:42PM +0100, Ard Biesheuvel wrote:
>>> @@ -393,6 +393,20 @@ static void __init cpuid_init_hwcaps(void)
>>>       vmsa = (read_cpuid_ext(CPUID_EXT_MMFR0) & 0xf) >> 0;
>>>       if (vmsa >= 5)
>>>               elf_hwcap |= HWCAP_LPAE;
>>> +
>>> +     /* check for supported v8 Crypto instructions */
>>> +     isar5 = read_cpuid_ext(CPUID_EXT_ISAR5);
>>> +
>>> +     switch ((isar5 >> 4) & 0xf) {
>>> +     case 2: elf_hwcap2 |= HWCAP2_PMULL;     /* pmull implies aes */
>>> +     case 1: elf_hwcap2 |= HWCAP2_AES;
>>> +     }
>>> +     if (((isar5 >> 8) & 0xf) == 1)
>>> +             elf_hwcap2 |= HWCAP2_SHA1;
>>> +     if (((isar5 >> 12) & 0xf) == 1)
>>> +             elf_hwcap2 |= HWCAP2_SHA2;
>>> +     if (((isar5 >> 16) & 0xf) == 1)
>>> +             elf_hwcap2 |= HWCAP2_CRC32;
>>
>> Reading through the ARMv7 ARM, the ISAR registers seem to work in a way
>> that "feature >= N" is sufficient to test for something (in other words,
>> the feature revision bits build on previous instructions added by older
>> revisions of that feature.)
>>
>
> There was quite some discussion about that when we implemented this
> for arm64. Perhaps Steve wants to elaborate on the details, because I
> don't remember them exactly.
>
>> Hence why PMULL implies AES - that follows the same pattern.  So, I wonder
>> if those == should all be >=, and there should be a "default:" before
>> "case 2:" with the zero case handled separately.
>>
>
> Quoting from my version of the ARM ARM (DDI0487A_d):
>
> AES, bits [7:4]
> Indicates whether AES instructions are implemented in AArch32.
> 0000 No AES instructions implemented.
> 0001 AESE, AESD, AESMC, and AESIMC implemented.
> 0010 As for 0001 , plus PMULL/PMULL2 instructions operating on 64-bit
> data quantities.
> All other values are reserved.
>
> Even though they are obviously not bitfields, 'reserved' to me
> suggests that it is still incorrect to assume both PMULL and AES
> capability for values not listed yet > 0b0010.
> The same applies to the other blocks: all other values are reserved.
>

Replying to self: looking at the arm64 code, it seems the 4-bit block
are signed quantities, and the negative valiues are reserved.
This means only signed higher values should be considered incremental,
and values with bit 4 set should be ignored.

However, I can't find anything about it in the ARMv8 ARM.

If you prefer, I can rework the patch to duplicate the compat code in
arm64: at least they will be the same then.

------------------------>8---------------------------
features = read_cpuid(ID_ISAR5_EL1);
block = (features >> 4) & 0xf;
if (!(block & 0x8)) {
switch (block) {
default:
case 2:
compat_elf_hwcap2 |= COMPAT_HWCAP2_PMULL;
case 1:
compat_elf_hwcap2 |= COMPAT_HWCAP2_AES;
case 0:
break;
}
}

block = (features >> 8) & 0xf;
if (block && !(block & 0x8))
compat_elf_hwcap2 |= COMPAT_HWCAP2_SHA1;

block = (features >> 12) & 0xf;
if (block && !(block & 0x8))
compat_elf_hwcap2 |= COMPAT_HWCAP2_SHA2;

block = (features >> 16) & 0xf;
if (block && !(block & 0x8))
compat_elf_hwcap2 |= COMPAT_HWCAP2_CRC32;
------------------------>8---------------------------