NetBSD Problem Report #59149

From www@netbsd.org  Thu Mar  6 15:02:53 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 96F091A9239
	for <gnats-bugs@gnats.NetBSD.org>; Thu,  6 Mar 2025 15:02:53 +0000 (UTC)
Message-Id: <20250306150252.240B01A923C@mollari.NetBSD.org>
Date: Thu,  6 Mar 2025 15:02:52 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: expose id_aa64*_el1 registers to userland
X-Send-Pr-Version: www-1.0

>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
>Last-Modified:  Fri Mar 07 10:10:01 +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.

>Audit-Trail:
From: matthew green <mrg@eterna23.net>
To: gnats-bugs@netbsd.org
Cc: port-arm-maintainer@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: re: port-arm/59149: expose id_aa64*_el1 registers to userland
Date: Fri, 07 Mar 2025 21:05:40 +1100

 i think i'd rather the hwcap method, instead of forcing a
 trap-and-emulate for all process startup.

 be aware that different cpus on an Arm system may not all
 support the same set of cpu features.  there are apps that
 end up having to be told to run on one or the other only,
 so any choices in libc startup etc should consider this.

 (this is also true on intel cpus with both p- and e- cores.)


 .mrg.

Home	PR Database Search