internal/cpu: support darwin/arm64 CPU feature detection [freeze exception]

[martisch]

darwin/arm64 does not support CPUID or HWCAP CPU feature detection like other operating systems on arm64 currently supported by Go.

A new way using sysctlbyname will need to be implemented to detect if for example hw.optional.armv8_1_atomics is set to 1.

https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code

If someone has an M1 Apple Silicon Mac please post the output of:
sysctl -a | grep "hw\.optional"

[FiloSottile]

hw.optional.floatingpoint: 1
hw.optional.watchpoint: 4
hw.optional.breakpoint: 6
hw.optional.neon: 1
hw.optional.neon_hpfp: 1
hw.optional.neon_fp16: 1
hw.optional.armv8_1_atomics: 1
hw.optional.armv8_crc32: 1
hw.optional.armv8_2_fhm: 1
hw.optional.armv8_2_sha512: 1
hw.optional.armv8_2_sha3: 1
hw.optional.amx_version: 2
hw.optional.ucnormal_mem: 1
hw.optional.arm64: 1

from my MacBook Pro M1.

[FiloSottile]

I'd like to request a freeze exception for this. Without hardware support, AES is not only extremely slow, but also not constant time, which is a security issue. crypto/tls will switch away from it, but not all applications can dynamically fallback, and not all peers support good alternatives.

The implementation is Go 1.16 would have to be scoped to only darwin/arm64 (not replacing the one in the other OSes), but if it is I think it would have very limited chances of affecting other targets, and darwin/arm64 will inevitably be in flux during the freeze anyway.

/cc @rsc @golang/release

[mundaym]

Can we just set aes, pmull, sha1 and sha2 to true for the darwin/arm64 target? It doesn't look like they are optional. That seems like a low risk change for Go 1.16 and then some sort of sysctl parsing could be added for Go 1.17 for atomics etc.

[martisch]

A low complexity workaround since there is only one Apple Silicon Chip (except the DTK which should be similar and testable) is that for darwin/arm64 we just hardcode the supported arm64 features in internal/cpu and @FiloSottile + @cherrymui can test that this works on their Apple Silicon Macs with ./all.bash. internal/cpu is only used by the standard library and I would expect any code dependent on those CPU features to have tests.

Then for go1.17 we can follow up with runtime CPU feature checks.

Im working on a CL to test the hard coding of CPU features.

[FiloSottile]

We have to consider that Go 1.16 will have to work correctly until 2022, and while I don't expect new Apple Silicon chips to drop such core features, we don't really know in advance. Binaries built with Go 1.16 might also stick around longer than Go 1.16 itself, and this is logic that would end up embedded in all of them.

[gopherbot]

Change https://golang.org/cl/271986 mentions this issue: internal/cpu: set features used by Apple Silicon M1 for darwin/arm64