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

On Tue, Jul 22, 2025 at 11:46 AM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
>
> On Tue, Jul 22, 2025 at 11:32 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > While getentropy() has better portability, according to the
> > getentropy() manual, the maximum length is limited to 256 bytes. It
> > works in some cases such as generating UUID data but seems not
> > appropriate for our general pg_strong_random() use cases.
>
> I imagine that the code would look very similar to your patch, though
> (loop, in chunks of size GETENTROPY_MAX, until the required length is
> met). Without looking too deeply, I have to say that implementing a
> newer POSIX API as opposed to a Linux-specific one does seem like a
> better cost-benefit tradeoff, if we decide to do this.
>
> Can you talk more about this part:
>
> > On my environment,
> > getrandom() is faster than RAND_bytes() so I thought there are some
> > cases where users want to use the getrandom() source rather than
> > RAND_bytes(), but I'm not sure since there is also a difference in the
> > secureness.
>
> That is _really_ surprising to me at first glance. I thought
> RAND_bytes() was supposed to be a userspace PRNG, which I would
> naively expect to take much less time than pulling data from Linux.
> (Once the OpenSSL PRNG has been seeded, that is.) Are there any other
> details about your environment (or the test itself) that are unusual?

Yes, it surprised me too. The environment I used for this benchmark was:

% cat /etc/redhat-release
Red Hat Enterprise Linux release 8.10 (Ootpa)
% uname -r
4.18.0-553.22.1.el8_10.x86_64
% rpm -qa | grep openssl
openssl-libs-1.1.1k-14.el8_6.x86_64
openssl-debugsource-1.1.1k-14.el8_6.x86_64
rubygem-openssl-2.1.2-114.module+el8.10.0+23088+750dc6ca.x86_64
openssl-devel-1.1.1k-14.el8_6.x86_64
openssl-pkcs11-0.4.10-3.el8.x86_64
openssl-1.1.1k-14.el8_6.x86_64
openssl-debuginfo-1.1.1k-14.el8_6.x86_64
% openssl version
OpenSSL 1.1.1k  FIPS 25 Mar 2021

and I measured the execution time of the following query:

explain analyze select uuidv4() from generate_series(1, 1_000_000);

The result is:

getrandom: 517.120ms
RAND_bytes: 1150.051 ms
/dev/urandom: 1862.483 ms

Since on the above environment I used an old Linux kernel and openssl
version, I've does the same benchmark on another environment:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.2 LTS
Release:        24.04
Codename:       noble
$ apt list --installed | grep ssl
libssl-dev/noble-updates,noble-security,now 3.0.13-0ubuntu3.5 amd64 [installed]
libssl3t64/noble-updates,noble-security,now 3.0.13-0ubuntu3.5 amd64
[installed,automatic]
libxmlsec1t64-openssl/noble,now 1.2.39-5build2 amd64 [installed,automatic]
openssl/noble-updates,noble-security,now 3.0.13-0ubuntu3.5 amd64
[installed,automatic]
python3-openssl/noble,now 23.2.0-1 all [installed,automatic]
ssl-cert/noble,now 1.1.2ubuntu1 all [installed,automatic]

The trend of the results were similar:

getrandom: 497.061 ms
RAND_bytes: 1152.260 ms ms
/dev/urandom: 1696.065 ms

Please let me know if I'm missing configurations or settings to
measure this workload properly.

Regards,

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