On 2025-03-16 at 21:51:45, Ramsay Jones wrote: > Ah, OK, thanks! While researching this I was only concerned about when > On cygwin, the arc4random_buf() implementation seems to have been imported > from OpenBSD, and uses a chacha_encrypt_bytes() function call during the > process of creating the random bytes (see newlib/libc/stdlib/arc4random.c > in the cygwin repo [0]). Also, the getrandom() and getentropy() functions > are simple wrappers around an RtlGenRandom() call (see winsup/cygwin/libc/\ > getentropy.cc in [0]). Yeah, that's similar to what I'd expect to see on the BSDs, except that `getrandom` or `getentropy` is the actual system call. > The glibc implementation of arc4random_buf() (see [1]), as you say, is just > a simple wrapper around the Linux 'getrandom syscall'. In addition, we can > also confirm that getrandom() (see [2]) and getentropy() (see [3]) are also > simple wrappers around the 'getrandom syscall'. However, I don't see the > 'extra function call' you refer to above. (Yes, all the layers of macros does > obscure things somewhat, but I don't see that extra function call). There's a call to `__getrandom_nocancel` in a loop, which I believe is the function wrapping the system call. It's probably inlined, so it's not that big a deal, though. > As you say, arc4random() is less available on Linux, so getrandom() makes > for a better default. > > Anyway, I guess that means the meson build needs to be modified, since it > currently selects arc4random() on Linux (this is OK on cygwin, see above). It's not the end of the world if the meson build system automatically prefers `arc4random` over `getrandom`. That's a sensible default in the general case, and I believe that the use case is generating temporary files, which will always incur the cost of a context switch and a disk access, so in general the performance difference would be negligible anyway. It's not a hot path, since nobody expects us to write millions of loose objects, pack files, or other temporary files in the typical case. I _do_ think that if we're specifying a default in `config.mak` on Linux, `getrandom` is the right choice, and I think we can probably just hard-code that now and let people override it if they're using a system older than our supported environments that needs `/dev/urandom`. POSIX 1003.1-2024 specifies `getentropy`, so my guess is that we'll see that on more and more systems as we go on, and the other choices will be less and less necessary, but we're not there yet. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature