Re: Support getrandom() for pg_strong_random() source

On Wed, Aug 27, 2025 at 4:48 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Tue, Aug 26, 2025 at 12:42 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> >
> > > On 26 Aug 2025, at 00:38, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> > >
> > > On Mon, Aug 25, 2025 at 3:22 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > >>
> > >> 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).
> > >
> > > Interesting idea. (Are there any users reading along who would
> > > definitely use such a feature?)
> >
> > I worry about the added complexity this would bring. It's already quite
> > complicated to configure postgres, and making an informed decision about which
> > RNG source to choose for cryptographically strong random won't be easy without
> > domain knowledge.
> >
> > Taking a step back and re-reading the thread, this started as a proposal to
> > improve uuid generation on non-Windows platforms when not using OpenSSL. While
> > non-SSL installations will be incredibly rare in production, it will likely be
> > a bit more common in PG development situations and speeding up test-runs in
> > such situations has value. I think this thread has shown merit to the idea of
> > replacing using /dev/urandom with a more modern API, but after sleeping on it
> > I'm less convinced that a'la carte CSPRNG configuration has enough upsides to
> > warrant the risk of users accidentally becoming non-FIPS compliant.
>
> The primary motivation is to enhance the performance of random data
> generation and UUID creation in scenarios where FIPS compliance is not
> mandatory. As I previously reported[1], getrandom() demonstrates
> superior performance for small random data operations, with the
> efficiency gain becoming even more significant in newer kernels thanks
> to the vDSO implementation of getrandom() (note that I assume
> cryptographic equivalence between random data generated by
> RAND_bytes() in non-FIPS mode and that produced by getrandom()).
>
> Although this would introduce additional configuration complexity, I
> guess that FIPS-compliant random data is unnecessary for most users,
> and getrandom()'s output is typically sufficient for many
> implementations. I think while maintaining RAND_bytes() as the default
> option for OpenSSL-enabled installations, we could somehow provide
> users with the flexibility to opt for getrandom() when preferred.

I've drafted this idea and attached two patches. The first patch
allows the user to select the random source function used in the
backend. 'openssl' is the default value if PostgreSQL is built with
openssl but users can set it to 'system' use the '/dev/urandom/'
approach (or CryptGenRandom on Windows) instead if they want. In
frontend code, there is nothing changed; the actual implementation of
pg_strong_random is chosed at build time and openssl's RAND_bytes() is
always used if the source code is built with openssl. Therefore, it
doesn't break any existing use cases but provides a way to select the
random source function.The second patch adds support for getrandom()
as the default random source of 'system' random source type on
Unix-like platforms.

With these two patches, for example, users can set random_source_type
to 'system' in the configuration file or a connection string in order
to use getrandom() for random data generation for UUID generation even
on openssl-enabled builds:

% echo "show random_source_type; select uuidv7();" | bin/psql -d
"dbname=postgres port=5432 options='-c random_source_type=openssl'" -X
random_source_type
--------------------
openssl
(1 row)

uuidv7
--------------------------------------
01997599-b6b6-7590-9825-f36253059956
(1 row)

% echo "show random_source_type; select uuidv7();" | bin/psql -d
"dbname=postgres port=5432 options='-c random_source_type=system'" -X
random_source_type
--------------------
system
(1 row)

uuidv7
--------------------------------------
01997599-f069-76b6-9ce2-0308d0cd6a0b
(1 row)

Regards,

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