port-arm/59149: expose id_aa64*_el1 registers to userland

[campbell+netbsd%mumble.net@localhost]

>Number:         59149
>Category:       port-arm
>Synopsis:       expose id_aa64*_el1 registers to userland
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-arm-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 06 15:05:00 +0000 2025
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, ...
>Organization:
The AArch64BSD FounIllegal instruciton (core dumped)
>Environment:
>Description:
Currently, in order to detect CPU support for features like SIMD and AES, userland is required to either:

(a) query sysctl nodes like machdep.cpu0.cpu_id, which requires unbounded memory allocation typically done through malloc in libc -- a nonstarter for contexts like ELF constructors and ifunc selectors (PR lib/59147: sysctl: bounded-memory lookups by name <https://gnats.NetBSD.org/59147>); or

(b) just try executing the SIMD or AES instructions with a SIGILL handler that longjmps out, as OpenSSL does.

Neither option is particularly appealing.
>How-To-Repeat:
do CPU feature detection in a gnarly context
>Fix:
Linux and FreeBSD pass an ELF auxiliary vector entry called AT_HWCAP, or AT_HWCAP2 (or AT_HWCAP3/4/...); we could follow suit.  Not sure how standardized the bits passed through these entries are.  We don't currently have a public libc API for querying the auxiliary vector, though.  (There is _dlauxinfo but it is kinda private, not really meant to be exposed to applications.)

We could allow userland to execute  MRS xN, ID_*_EL1  instructions, by emulating them in the kernel when the instruction traps, with an allowlist of id bits/fields.  This doesn't require inventing or exposing any new public libc interfaces -- the interface is already defined in the Arm architecture spec.