| Message ID | 20250416231835.2492562-14-ramsay@ramsayjones.plus.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | cdda67de0316ec29dfc1e290bb7f2154b7b95ee8 |
| Headers | show |
| Series | miscellaneous build mods (part 1) | expand |
Ramsay Jones <ramsay@ramsayjones.plus.com> writes: > Commit 05cd988dce ("wrapper: add a helper to generate numbers from a > CSPRNG", 2022-01-17) added a csprng_bytes() function which used one > of several interfaces to provide a source of cryptographically secure > pseudorandom numbers. The CSPRNG_METHOD make variable was provided to > determine the choice of available 'backends' for the source of random > bytes. > > Commit 05cd988dce did not set CSPRNG_METHOD in the Linux section of > the config.mak.uname file, so it defaults to using '/dev/urandom' as > the source of random bytes. The 'backend' values which could be used > on Linux are 'arc4random', 'getrandom' or 'getentropy' ('openssl' is > an option, but seems to be discouraged). > > The arc4random routines (ar4random_buf() is the one actually used) were arc4random_buf(), if I am not mistaken? > added to glibc in version 2.36, while both getrandom() and getentropy() > were included in 2.25. So, some of the more up-to-date distributions of > Linux (eg Debian 12, Ubuntu 24.04) would be able to use the 'arc4random' > setting. All currently supported distributions have glibc 2.25 or later > (RHEL 8 has v2.28) and, therefore, have support for the 'getrandom' and > 'getentropy' settings. OK. This explains that getrandom/getentropy have better availability than arc4random. > The arc4random routines on the *BSDs (along with cygwin) implement the > ChaCha20 stream cipher algorithm (see RFC8439) in userspace, rather than > as a system call, and are thus somewhat faster (having avoided a context > switch to the kernel). In contrast, on Linux all three functions are > simple wrappers around the same kernel CSPRNG syscall. OK. With this and the previous paragraph, we establish that there is no reason to use arc4random on Linux, while on BSDs and Cygwin, it is a natural choice. Very clearly explained. Thanks. > 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' on Linux. > Since there is no advantage, > in terms of performance, to the 'arc4random' setting, the 'getrandom' > setting should be preferred from an availability perspective. (Also, the > current uses of csprng_bytes() are not in any hot path). > > In order to set an appropriate default, set the CSPRNG_METHOD build > variable to 'getrandom' in the Linux section of the 'config.mak.uname' > file. > > Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> > --- > config.mak.uname | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/config.mak.uname b/config.mak.uname > index 330741eb5a..db22a8fb31 100644 > --- a/config.mak.uname > +++ b/config.mak.uname > @@ -50,6 +50,7 @@ ifeq ($(uname_S),Linux) > HAVE_ALLOCA_H = YesPlease > # override in config.mak if you have glibc >= 2.38 > NO_STRLCPY = YesPlease > + CSPRNG_METHOD = getrandom > HAVE_PATHS_H = YesPlease > LIBC_CONTAINS_LIBINTL = YesPlease > HAVE_DEV_TTY = YesPlease
On 17/04/2025 14:55, Junio C Hamano wrote: > Ramsay Jones <ramsay@ramsayjones.plus.com> writes: [snip] >> The arc4random routines (ar4random_buf() is the one actually used) were > > arc4random_buf(), if I am not mistaken? Oops, yes ... an unfortunate tyop! ;) Do you want a v4? (The cygwin v3 'make test' has been running for under two hours, I could Ctrl-C it ...) > >> added to glibc in version 2.36, while both getrandom() and getentropy() >> were included in 2.25. So, some of the more up-to-date distributions of >> Linux (eg Debian 12, Ubuntu 24.04) would be able to use the 'arc4random' >> setting. All currently supported distributions have glibc 2.25 or later >> (RHEL 8 has v2.28) and, therefore, have support for the 'getrandom' and >> 'getentropy' settings. > > OK. This explains that getrandom/getentropy have better > availability than arc4random. > >> The arc4random routines on the *BSDs (along with cygwin) implement the >> ChaCha20 stream cipher algorithm (see RFC8439) in userspace, rather than >> as a system call, and are thus somewhat faster (having avoided a context >> switch to the kernel). In contrast, on Linux all three functions are >> simple wrappers around the same kernel CSPRNG syscall. > > OK. With this and the previous paragraph, we establish that there > is no reason to use arc4random on Linux, while on BSDs and Cygwin, > it is a natural choice. > > Very clearly explained. Thanks. > Thanks! ATB, Ramsay Jones
Ramsay Jones <ramsay@ramsayjones.plus.com> writes: > On 17/04/2025 14:55, Junio C Hamano wrote: >> Ramsay Jones <ramsay@ramsayjones.plus.com> writes: > [snip] >>> The arc4random routines (ar4random_buf() is the one actually used) were >> >> arc4random_buf(), if I am not mistaken? > > Oops, yes ... an unfortunate tyop! ;) > > Do you want a v4? (The cygwin v3 'make test' has been running for under > two hours, I could Ctrl-C it ...) Nah, if you send one I will replace my copy with it, but in the meantime I'll locally make a typofix myself to v3. Thanks.
On 17/04/2025 21:13, Junio C Hamano wrote: > Ramsay Jones <ramsay@ramsayjones.plus.com> writes: > >> On 17/04/2025 14:55, Junio C Hamano wrote: >>> Ramsay Jones <ramsay@ramsayjones.plus.com> writes: >> [snip] >>>> The arc4random routines (ar4random_buf() is the one actually used) were >>> >>> arc4random_buf(), if I am not mistaken? >> >> Oops, yes ... an unfortunate tyop! ;) >> >> Do you want a v4? (The cygwin v3 'make test' has been running for under >> two hours, I could Ctrl-C it ...) > > Nah, if you send one I will replace my copy with it, but in the > meantime I'll locally make a typofix myself to v3. OK, thanks. I have made the change locally just in case there is a need to send another version. Hopefully, that won't be necessary! (The cygwin 'make test' just finished and, as expected, passed just fine). Thanks. ATB, Ramsay Jones
diff --git a/config.mak.uname b/config.mak.uname index 330741eb5a..db22a8fb31 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -50,6 +50,7 @@ ifeq ($(uname_S),Linux) HAVE_ALLOCA_H = YesPlease # override in config.mak if you have glibc >= 2.38 NO_STRLCPY = YesPlease + CSPRNG_METHOD = getrandom HAVE_PATHS_H = YesPlease LIBC_CONTAINS_LIBINTL = YesPlease HAVE_DEV_TTY = YesPlease
Commit 05cd988dce ("wrapper: add a helper to generate numbers from a CSPRNG", 2022-01-17) added a csprng_bytes() function which used one of several interfaces to provide a source of cryptographically secure pseudorandom numbers. The CSPRNG_METHOD make variable was provided to determine the choice of available 'backends' for the source of random bytes. Commit 05cd988dce did not set CSPRNG_METHOD in the Linux section of the config.mak.uname file, so it defaults to using '/dev/urandom' as the source of random bytes. The 'backend' values which could be used on Linux are 'arc4random', 'getrandom' or 'getentropy' ('openssl' is an option, but seems to be discouraged). The arc4random routines (ar4random_buf() is the one actually used) were added to glibc in version 2.36, while both getrandom() and getentropy() were included in 2.25. So, some of the more up-to-date distributions of Linux (eg Debian 12, Ubuntu 24.04) would be able to use the 'arc4random' setting. All currently supported distributions have glibc 2.25 or later (RHEL 8 has v2.28) and, therefore, have support for the 'getrandom' and 'getentropy' settings. The arc4random routines on the *BSDs (along with cygwin) implement the ChaCha20 stream cipher algorithm (see RFC8439) in userspace, rather than as a system call, and are thus somewhat faster (having avoided a context switch to the kernel). In contrast, on Linux all three functions are simple wrappers around the same kernel CSPRNG syscall. 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' on Linux. Since there is no advantage, in terms of performance, to the 'arc4random' setting, the 'getrandom' setting should be preferred from an availability perspective. (Also, the current uses of csprng_bytes() are not in any hot path). In order to set an appropriate default, set the CSPRNG_METHOD build variable to 'getrandom' in the Linux section of the 'config.mak.uname' file. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> --- config.mak.uname | 1 + 1 file changed, 1 insertion(+)