> Date: Sun, 7 Jul 2024 17:44:39 +0200
> From: Jeremie Courreges-Anglas <jca@wxcvbn.org>
> 
> On Sun, Jul 07, 2024 at 03:00:55PM +0200, Mark Kettenis wrote:
> > > Date: Sat, 6 Jul 2024 14:47:28 +0200
> > > From: Jeremie Courreges-Anglas <jca@wxcvbn.org>
> > > 
> > > On Thu, Jul 04, 2024 at 08:14:15AM -0600, Theo de Raadt wrote:
> > > > In glibc, getauxval(3) is a monster API that keeps growing additional
> > > > heads and tentacles.  Exporting a tiny version of it to userland is
> > > > worrying.
> > > 
> > > Agreed about getauxval.
> > 
> > Not sure what you folks mean with that.  Is the problem that there are
> > too many AT_xxx constants for which we would not want to add support?
> > That I do agree with.
> 
> Yep.
> 
> > So do yout think that adding just the few AT_xxx constants that we
> > care about would cause too many problems in ports?
> 
> (One common pattern visible in ports is to #define some AT_xxx
> constants (with a hardcoded value copied from Linux headers) if
> they're not already #defined.)
> 
> I fear that detection of the getauxval() symbol may trigger the use of
> Linux-specific code paths, possibly with no useful/usable fallback in
> case of an error.  Also, some ports may start to include <linux/*.h>
> headers along with their use of getauxval().  It would be a shame to
> implement getauxval() and yet need non-trivial patches in ports.
> 
> > > > When the real problem here is a tiny little check to use done only
> > > > internal to only our libc, and therefore why not use an OpenBSD private
> > > > interface.
> > > 
> > > Indeed we could use a private API for this specific need.  But the
> > > problem is not just about our libc, ports also want a way to query
> > > hardware capabilities.  We usually have to patch them to use a
> > > sysctl(2) or just drop the code that detects such capabilities.
> > > I feel like implementing elf_aux_info(3) should be considered.  Has
> > > someone already tried that?  If people don't object, that could be a
> > > todo entry for c2k24.
> > 
> > So elf_aux_info(3) is just getauxval(3) with a somewhat different API.
> > It is a bit better in the sense that it unambiguously tells you if an
> > AT_xxx value isn't supported.
> > 
> > Are you less worried about us not implementing all the AT_xxx defines
> > that FreeBSD has?
> 
> Yes.  Dumb comparison:
> 
>   https://www.man7.org/linux/man-pages/man3/getauxval.3.html 34 defines
>   https://man.freebsd.org/cgi/man.cgi?elf_aux_info(3) 11 defines
> 
> Compare that to the 8 AUX_xxx values handled in our kern/exec_elf.c...

And perhaps more importantly, FreeBSD doesn't have bad ones like
AT_SECURE.

> BTW, we currently always export 0 for AUX_flags.  The comment in
> exec_elf.h says "processor flags".  Have you considered reusing this
> for a quick compiler-rt hack?

AUX_flags would be AT_FLAGS, which is related to e_flags in the ELF
header.  Solaris used this to mark binaries that (unconditionally) use
certain instruction set extensions.  I suppose we could use it on
arm64 but AT_HWCAP and AT_HWCAP2 on Linux and FreeBSD provide more
flags than we could fit in AT_FLAGS.

If we go this route we do want the features to align with what Linux
and FreeBSD use.  I don't think we want to burden porters with
figuring out what OpenBSD feature bit maps onto what Linux uses.

> > I suspect that there is a much smaller number of ports that support
> > elf_aux_info(3).
> 
> Well, maybe it's a good thing? ;)
> 
> More seriously, I've started an amd64 bulk build on a system with a
> dumb elf_aux_info() that always returns ENOENT.  I should have numbers
> in 2 days for ports that may automatically pick it up.
> 
> There would also be a bunch of other ports where we'd have to add an
> ugly "|| defined(__OpenBSD__)" chunk to the FreeBSD code path, but at
> least that's something that could be upstreamed.
> 
> Feedback from other porters would be welcome.
> 
> > > > This means it could be built upon the assumption "this is an
> > > > openbsd binary", and use a sysctl interface.  After 2 months, there will
> > > > be only one kind of binary.
> 
> (As mentioned above this could be done without a sysctl.)
> 
> -- 
> jca
> 
>