From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
Cc: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Support getrandom() for pg_strong_random() source |
Date: | 2025-07-22 23:22:33 |
Message-ID: | CAD21AoDdzBGJ3aS1x7_Sb2qpJHvYE5Ysd2SOGxC5GAR7o6C8iA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 22, 2025 at 11:46 AM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
>
> On Tue, Jul 22, 2025 at 11:32 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-07-22 23:34:14 | Re: Missing NULL check after calling ecpg_strdup |
Previous Message | Peter Geoghegan | 2025-07-22 23:13:23 | Re: index prefetching |