From: Mark Kettenis Subject: Re: arm64 LSE support in userland To: Jeremie Courreges-Anglas Cc: deraadt@openbsd.org, tech@openbsd.org, brad@comstyle.com Date: Sun, 07 Jul 2024 15:00:55 +0200 > Date: Sat, 6 Jul 2024 14:47:28 +0200 > From: Jeremie Courreges-Anglas > > 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. So do yout think that adding just the few AT_xxx constants that we care about would cause too many problems 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? I suspect that there is a much smaller number of ports that support elf_aux_info(3). > > 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.