Re: Support getrandom() for pg_strong_random() source - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Support getrandom() for pg_strong_random() source
Date
Msg-id CAD21AoD6KgevUbb=xb3eobWC9eo6eHJ4a-qepq6kAUN9ufwsuw@mail.gmail.com
Whole thread Raw
In response to Re: Support getrandom() for pg_strong_random() source  (Jacob Champion <jacob.champion@enterprisedb.com>)
List pgsql-hackers
On Fri, Aug 8, 2025 at 3:37 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
>
> On Fri, Aug 8, 2025 at 3:25 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > 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.
>
> Thanks for finding that! Ah, FIPS:
>
> > More specifically the data returned by getentropy(2) has not had the required FIPS 140-2 processing for the DRBG
appliedto it. 
>
> So FIPS compliance is a case where "a stream of numbers would be
> suitable for seeding a CSPRNG, but not suitable as output from a
> CSPRNG". That's evidence enough for me to abandon my preference for
> getentropy() (whether Solaris still does that or not).

Makes sense.

>
> I've been looking at libsodium's randomness implementations [1]:
>
> > On Windows systems, the RtlGenRandom() function is used.
> > On OpenBSD and Bitrig, the arc4random() function is used.
> > On recent FreeBSD and Linux kernels, the getrandom system call is used.
> > On other Unices, the /dev/urandom device is used.
>
> (Note that libsodium has some internal concept of a "safe" arc4random
> implementation, which it locks to certain platforms. If an OS is still
> literally using RC4 we would not want to use it.)
>
> So, my next question: is getrandom() always preferable to /dev/urandom?

I believe so. While /dev/urandom source should be kept as a fallback
for older kernels, we should use getrandom() if available. For
example, getrandom() can be used even in the face of file-descriptor
exhaustion and lack of access to the random devices[1]. Also, it would
be much faster than reading /dev/urandom as I shared the benchmark
result[2].

Regards,

[1] https://lwn.net/Articles/884875/
[2] https://www.postgresql.org/message-id/CAD21AoD1%2B6FwGb0d4W3YEwOVJi_McuyuvpnjUJE8B8Ejy21MMw%40mail.gmail.com

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



pgsql-hackers by date:

Previous
From: Greg Burd
Date:
Subject: Re: [PATCH] bms_prev_member() can read beyond the end of the array of allocated words
Next
From: Noboru Saito
Date:
Subject: Re: [PATCH] Proposal: Improvements to PDF stylesheet and table column widths