All of lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Ramsay Jones <ramsay@ramsayjones.plus.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	GIT Mailing-list <git@vger.kernel.org>,
	Patrick Steinhardt <ps@pks.im>,
	Adam Dinwoodie <git@dinwoodie.org>
Subject: Re: [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux
Date: Sun, 16 Mar 2025 23:52:05 +0000	[thread overview]
Message-ID: <Z9dkJb-HOIQmsEqs@tapette.crustytoothpaste.net> (raw)
In-Reply-To: <654de230-07cb-4ffe-bfc4-ca0e1d6d3572@ramsayjones.plus.com>

[-- Attachment #1: Type: text/plain, Size: 2632 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

      reply	other threads:[~2025-03-16 23:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-15  2:49 [PATCH 12/12] config.mak.uname: add a note about CSPRNG_METHOD for Linux Ramsay Jones
2025-03-16  0:28 ` brian m. carlson
2025-03-16 20:41   ` Junio C Hamano
2025-03-16 21:57     ` Ramsay Jones
2025-03-19 13:30     ` Patrick Steinhardt
2025-03-20  1:28       ` Ramsay Jones
2025-03-20  5:20         ` Patrick Steinhardt
2025-03-20 16:41           ` Ramsay Jones
2025-03-16 21:51   ` Ramsay Jones
2025-03-16 23:52     ` brian m. carlson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z9dkJb-HOIQmsEqs@tapette.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@dinwoodie.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ps@pks.im \
    --cc=ramsay@ramsayjones.plus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.