libbsd and arc4random()

[Guillem Jover]

Hi!

On Fri, 2022-12-30 at 13:29:23 +0100, Alejandro Colomar wrote:
> glibc developers consider libbsd's arc4random(3) unsafe, since there are
> situations in which it should drop the buffer but which can't be detected
> (and libbsd's source code seems to acknowledge this).  They added
> arc4random(3) in glibc with kernel support, which is safer to use.

Do you have references to that. The comment I see in the libbsd code
(from the OpenBSD implementation, used in libressl too) mentions
clone(3), but I only see as an obvious issue CLONE_PID which is only
a problems for old kernels?

> Could you somehow make that libbsd only provide arc4random(3) if glibc
> doesn't provide it?

AFAICS the glibc implementation uses blocking calls? Which ISTR was an
issue in the past (on Debian at least) on some systems that blocked
during boot due to not enough entropy. So switching the implementation
could be problematic, and I'd rather people switch, by linking against
the newer glibc version.

> You'll probably have to use aliases and linker magic,
> to not load your function before the glibc one, I guess.  Or maybe just
> compile it conditionally on the glibc version.

If the system libc contains an arc4random(3) implementation, then code
linked against that, will always be preferred already:

  ,---
  $ cat arc4.c
  #include <stdlib.h>
  int main() { arc4random(); return 0; }
  $ gcc $(pkg-config --libs --cflags libbsd-overlay) arc4.c -o arc4
  $ objdump -T arc4|grep arc4random
  0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.36) arc4random
  `---

Otherwise I guess I could use something similar to the MD5 wrappers,
but that would need to be conditional on a system with a libc providing
the functions. But then libbsd contains a couple of functions not
found on glibc anyway so, this would probably be a mess (and it
probably is already with a mixed glibc + libbsd linking).

Thanks,
Guillem