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...

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?

> 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