Re: deconflicting new syscall numbers for 6.11

[Adhemerval Zanella Netto]

On 06/07/24 12:30, Florian Weimer wrote:
> * 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,F
> 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.

The BSD seems to use use it extensively, specially in the base system for
tools like smtpd/relayd/etc. as alternative to rand/random and to avoid 
pulling a RNG from cryptographic library. But I agree that for glibc, 
arc4random being just a shim over getrandom is only helpful as a way to
avoid a biased implementation of arc4random_uniform (which is quite 
common if you check on the internet about it...).

Also, this vDSO proposal and they way the now is up to kernel to manage
the RNG state would adds some extra considerations for libc getrandom 
implementation.  The libc symbol now is fully async-signal and thread-safe
due being just a syscall wrapper, and to sane manage the way the vDSO 
buffer is designed (either by vgetrandom_alloc or mmap), the runtime 
will need a way to allocate and manage this threads states with a block 
allocator (assuming runtime would like to keep a per-thread state).

For arc4random, the libbsd way or the old way glibc used to do (prior
Jason refactor), would be simple because it was never intended to be
async-signal.  But for getrandom it would require to either have a
async-signal-safe malloc implementation (to keep track of the extra
states) or a block allocation over mmap (which adds some extra memory 
usage). So getrandom now will potentially uses 2 more pages, which is 
not the end of world since interface is designed to allow failure, but 
it is something to consider.