Re: deconflicting new syscall numbers for 6.11

[Florian Weimer <fweimer@redhat.com>]

* Zack Weinberg:

> Without commenting on the rest of this...
>
> On Sat, Jul 6, 2024, at 6:01 AM, Florian Weimer wrote:
>> The arc4random implementation in glibc was never intended to displace
>> randomness generation for cryptographic purposes.
>
> ...arc4random on the BSDs (particularly on OpenBSD) *is* intended to be
> suitable for cryptographic purposes, and, simultaneously, intended to be
> fast enough that user space programs should never hesitate to use it.
> Therefore, Linux+glibc needs to be prepared for user space programs to
> use it that way -- expecting both speed and cryptographic strength --
> or else we shouldn't have added it at all.

None of the major cryptographic libraries (OpenSSL, NSS, nettle,
libgcrypt, OpenJDK, Go, GNUTLS) use arc4random in their upstream
version.  If the BSDs use arc4random rather than the bundled generators,
they must have downstream-only patches.  I also don't see why someone
writing a new library from scratch would use arc4random because its
addition to glibc is still quite recent, and it provides no performance
advantage over going to the kernel interfaces directly.

Thanks,
Florian