Re: [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux

From: Ramsay Jones <ramsay@ramsayjones.plus.com>
Date: Mar 16, 2025, 21:51 UTC
Message-ID: <654de230-07cb-4ffe-bfc4-ca0e1d6d3572@ramsayjones.plus.com>
In-Reply-To: <Z9YbJFJjtXNYnTzk@tapette.crustytoothpaste.net>

Hi Brian,

On 16/03/2025 00:28, brian m. carlson wrote:

> On 2025-03-15 at 02:49:18, Ramsay Jones wrote:

[snip]

Show 25 quoted lines

>> 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