Hi Brian, On 16/03/2025 00:28, brian m. carlson wrote: > On 2025-03-15 at 02:49:18, Ramsay Jones wrote: [snip] >> If the meson build system is used on a newer platform, then they will be >> configured to use 'arc4random', whereas the make build will currently >> default to using '/dev/urandom'. Add a note to the config.mak.uname file, >> in the Linux section, to prompt make users to override CSPRNG_METHOD in >> the config.mak file, if appropriate. > > arc4random operates differently on Linux than it does on the BSDs, and > the right choice on Linux is `getrandom`. > > The reason is that on the BSDs, a userspace ChaCha20 which is seeded > from the kernel is used, along with an integer representing whether it's > inititalize, and this state is stored in a page that is zeroed on fork, > so that it automatically becomes uninitialized then (and is hence > reseeded). Because it is in userspace, it avoids the overhead of a > syscall, and is thus usually faster. arc4random has also been around > longer than getrandom or getentropy on the BSDs and is widely supported > there, and so it's generally the right choice (and hence, the default). > > When arc4random was added to glibc, the Linux kernel CSPRNG maintainer > argued that it was not a secure approach (I disagree), and convinced the > glibc maintainers to just make it a wrapper around the Linux kernel > CSPRNG, which it now is. So there's no actual benefit to calling > arc4random versus getrandom, and since it's newer and less commonly > available than getrandom, as well as slightly slower (because of an > extra function call), getrandom should be preferred. Ah, OK, thanks! While researching this I was only concerned about when the functions were available. I didn't give quality/performance a minutes thought! ;) [I am aware, of course, that newer doesn't automatically mean better. It seems I forgot about that here - my bad! :( ] However, this afternoon, while I was waiting for the 'meson test' on cygwin to finish, I had a quick look at the implementation(s) on glibc and cygwin. 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]). 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). What am I missing? [I haven't actually done any tests for quality/performance, so I am quite prepared to take your word for it! :) ] 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). [I was writing an autoconf test for this, which will also need to change!] [0] git://cygwin.com/git/newlib-cygwin.git [1] https://codebrowser.dev/glibc/glibc/stdlib/arc4random.c.html [2] https://codebrowser.dev/glibc/glibc/sysdeps/unix/sysv/linux/getrandom.c.html [3] https://codebrowser.dev/glibc/glibc/sysdeps/unix/sysv/linux/getentropy.c.html > > All Linux distros within our current support window have glibc 2.25 or > newer (RHEL 8 being the oldest one), so we may want to just default to > getrandom on Linux. So, Yes, this patch needs to be dropped. Thanks! ATB, Ramsay Jones
