From: Stuart Henderson <stu@spacehopper.org>
Subject: Re: arm64 LSE support in userland: introduce elf_aux_info?
To: j@bitminer.ca
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, tech@openbsd.org
Date: Fri, 12 Jul 2024 21:24:59 +0100

On 2024/07/12 16:08, j@bitminer.ca wrote:
> Some features are fairly complicated to understand; e.g. the array
> of avx instructions varies dramatically with implementation (code
> name of the cpu). Fortunately cpuid on Intel is unprivileged so
> software can decide

Well, with avx512, it also depends on whether the OS supports it. If not
then no matter what CPU, it won't work.

> then the porter has to understand this and somehow restrict usage.

if the OS can restrict the information presented to userland when it
knows that something won't work, that makes things much simpler for
the porter (who often won't have enough hardware variants to test).

> If SVE is not available (because context switch does not preserve
> the register file) then so be it.  Again the porter has to control
> for this.

Not if the OS can control for this.

> To be sure, I would support a dmesg output which matches, within
> the supported features

Requiring that a port parse dmesg for cpu features is complete bullshit.

> > > In particular you may well find that some of these codepaths break
> > > branch-target CFI.
> 
> Interesting risk there.  is there somewhere to learn more?

https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension