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 CAD21AoCcJ4vESbn-N5eJ6rjDvrXG5K5qXGGSVWF2s-kivoMfdA@mail.gmail.com
Whole thread Raw
In response to Re: Support getrandom() for pg_strong_random() source  (Jacob Champion <jacob.champion@enterprisedb.com>)
Responses Re: Support getrandom() for pg_strong_random() source
List pgsql-hackers
On Mon, Aug 25, 2025 at 1:07 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
>
> On Mon, Aug 25, 2025 at 11:30 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > > Gathering a couple of considerations from upthread:
> > > - FIPS behavior
> >
> > Do you mean random numbers generated by getrandom() complaints FIPS?
> > Based on my research, there doesn't appear to be any explicit
> > statement indicating that Linux's CSPRNG module complies with FIPS
> > requirements. However, there is a proposal to implement LRNG[1], which
> > would be FIPS-compliant.
>
> Right. I guess what I'm asking with that particular bullet point is:
>
> If, tomorrow, I threw caution to the wind and proposed that we use
> getrandom() on Linux over OpenSSL by default, would any FIPS users
> complain? Or are they all using distributions that have already
> applied FIPS patches to the getrandom() part of the kernel anyway?

Valid point. I guess the approach of selecting the random number
source at compile time might be inflexible, and there does not seem to
be a one-size-fits-all solution when it comes to things like this. The
fact made me think we could have PostgreSQL select its random number
source when it starts up instead of compile time, giving us the
flexibility to cater to various scenarios. For instance, we could
introduce a GUC parameter that lets users specify their preferred
random number source. Or the server can automatically select it based
on the kernel's FIPS mode (i.e., checking
/proc/sys/crypto/fips_enabled).

Regards,

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



pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: Improve LWLock tranche name visibility across backends
Next
From: Masahiko Sawada
Date:
Subject: Use LW_SHARED in WakeupWalSummarizer() for WALSummarizerLock lock