Re: [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Mar 16, 2025, 23:52 UTC
- Message-ID
- <Z9dkJb-HOIQmsEqs@tapette.crustytoothpaste.net>
- In-Reply-To
- <654de230-07cb-4ffe-bfc4-ca0e1d6d3572@ramsayjones.plus.com>
On 2025-03-16 at 21:51:45, Ramsay Jones wrote:
Show 7 quoted lines
> 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.
Show 6 quoted lines
> 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.
Show 5 quoted lines
> 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