Re: Support getrandom() for pg_strong_random() source

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Support getrandom() for pg_strong_random() source
Date: 2025-08-08 22:24:47
Message-ID: CAD21AoAxtjvmFd57Z-o1FmiZo-5D5BsU3QHDQr4EtqTJ78_+6g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 30, 2025 at 2:04 PM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
>
> On Wed, Jul 30, 2025 at 12:58 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
> > I imagine a "get entropy" operation could be very slow or even blocking,
> > whereas a random number generator might just have to do some arithmetic
> > starting from the previous seed state.
>
> Agreed -- it could absolutely be slower, but if it's not slower in
> practice in a user's environment, is there a problem with using it as
> the basis for pg_strong_random()? That doesn't seem "wrong" to me; it
> just seems like a tradeoff that would take investigation.

Regarding glibc's getrandom() and getentropy() implementation[1],
getentropy() seems to be implemented as a wrapper of getrandom() in a
sense. That is, getrandom() has more fine grained control such as
specifying blocking behavior and the source (/dev/random or
/dev/urandom). glibc's getentropy() simply calls getrandom() with
flag=0 and 256 byte limitation. I think there is no difference between
random bytes generated by getrandom() and getentropy() in strength.
And according Linux manual for getentropy(),

A call to getentropy() may block if the system has just booted and the
kernel has not yet collected enough randomness to initialize the
entropy pool.

Which is the same behavior of calling getrandom() without GRND_NONBLOCK.

I believe FreeBSD's getentropy() is almost the same; it internally
calls getrandom()[2].

On the other hand, I found a blog post[3] (10 years-old post) that on
Solaris the output of getentropy() should not be used where randomness
is needed. I'm not sure it's still true but I guess that it might be
reasonable to consider that this is correct behavior in principle, and
that the behavior of glibc etc. is in some sense an exception.

Regards,

[1] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getentropy.c;h=a62c9fb09962d4918a9c8cdd5545ad803b62fb82;hb=d2097651cc57834dbfcaa102ddfacae0d86cfb66
[2] https://github.com/freebsd/freebsd-src/blob/main/lib/libc/gen/getentropy.c
[3] https://blogs.oracle.com/solaris/post/solaris-new-system-calls-getentropy2-and-getrandom2

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-08-08 22:27:44 Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
Previous Message Masahiko Sawada 2025-08-08 21:59:01 Re: Add CHECK_FOR_INTERRUPTS in pg_buffercache_pages while scanning the buffers