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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux