cpufeatures: aarch64 support (Linux and macOS/M4)

[tarcieri]

Adds preliminary support for runtime feature detection on aarch64 targets, presently restricted to the following set of target features which are present on both aarch64-unknown-linux-gnu and aarch64-apple-darwin targets:

• aes: AES support
• sha2: SHA1 and SHA256 support
• sha3: SHA512 and SHA3 support

Closes #378

[tarcieri]

Note: the comments here are taken directly from the output of:

$ rustc --target=aarch64-unknown-linux-gnu --print target-features

The output for these target features is the same on an aarch64-apple-darwin target.

I'm a bit confused because the target features aren't isomorphic to either the Linux ARM64 ELF hwcaps or the macOS sysctl flags.

Per the Linux ARM64 ELF hwcaps docs:

https://www.kernel.org/doc/html/latest/arm64/elf_hwcaps.html

HWCAP_SHA1: Functionality implied by ID_AA64ISAR0_EL1.SHA1 == 0b0001.
HWCAP_SHA2: Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0001.
HWCAP_SHA3: Functionality implied by ID_AA64ISAR0_EL1.SHA3 == 0b0001.
HWCAP_SHA512: Functionality implied by ID_AA64ISAR0_EL1.SHA2 == 0b0010.

That would suggest that the SHA-1 and SHA-3 hwcaps are independent of the others, and that SHA-2 support implies SHA-512 support.

macOS/M4 likewise has separate sysctl(3) flags for SHA-512 and SHA-3:

hw.optional.armv8_2_sha512: 1
hw.optional.armv8_2_sha3: 1

...but the rustc target-features suggest that sha2 implies SHA-1 support, and that sha3 implies SHA-512 support.

[tarcieri]

Marking this as ready for review.

I was able to extract the CPU-specific bits from the new! macro and factor them into respective modules, so the core macro that sets up the AtomicU8s and caches the detection results is shared between targets.

Linux and MacOS targets now work on aarch64. I configured CI to test a Linux target using cross, and tested a MacOS target locally on a M1 Mini.

AFAICT this is not a breaking change and should be fully compatible with the existing v0.1.0 release.

I think the biggest remaining question is my earlier comment about how Rust's ARM64 target features don't seem to fully align with Linux HWCAPs or MacOS armcaps, though the OS-level strategies seem consistent with each other as well as the ARM capability registers. Not sure what to do about that but if anything is wrong, it seems to be Rust's own target feature mapping as everything else (ARM64 docs, Linux, and macOS) are all consistent with each other.

@newpavlov mind taking a look?

[tarcieri]

Played around with a few different syntaxes for this macro and this is the best one I could come up with.

Open to suggestions for alternatives.

[tarcieri]

I'll move my concerns about the mappings of ARM CPU features Rust target features to a separate issue (edit: opened #395).

Going to go ahead and merge this, but I'll hold off on publishing the changes until next week to give @newpavlov some time to review.

Edit: okay, going to go ahead and ship a v0.1.1, but I won't ship any crates that depend on it. Everything that depends on it now only uses the x86/x86-64 support which should be unchanged by this PR.

If need be we can make breaking changes to the ARM backend.