Download raw body.
arm64 LSE support in userland: introduce elf_aux_info?
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
arm64 LSE support in userland: introduce elf_aux_info?