Re: Support getrandom() for pg_strong_random() source - Mailing list pgsql-hackers
| From | DINESH NAIR |
|---|---|
| Subject | Re: Support getrandom() for pg_strong_random() source |
| Date | |
| Msg-id | PN5P287MB4369429A26A04A6AC2649BA09C5CA@PN5P287MB4369.INDP287.PROD.OUTLOOK.COM Whole thread Raw |
| In response to | Re: Support getrandom() for pg_strong_random() source (Masahiko Sawada <sawada.mshk@gmail.com>) |
| List | pgsql-hackers |
Hi ,
On Tue, Jul 22, 2025 at 4:12 AM Dagfinn Ilmari Mannsåker
<ilmari@ilmari.org> wrote:
>
> Masahiko Sawada <sawada.mshk@gmail.com> writes:
>
> > On Tue, Jul 22, 2025 at 12:13 AM Michael Paquier <michael@paquier.xyz> wrote:
> >>
> >> On Mon, Jul 21, 2025 at 11:43:35PM -0700, Masahiko Sawada wrote:
> >> > The patch supports the getrandom() function as a new source of
> >> > pg_strong_random(). The getrandom() function uses the same source as
> >> > the /dev/urandom device but it seems much faster than opening,
> >> > reading, and closing /dev/urandom. Here is the execution time of
> >> > generating 1 million UUIDv4 data measured on my environment:
> >> >
> >> > HEAD(/dev/urandom): 1863.064 ms
> >> > Patched(getrandom()): 516.627 ms
> >>
> >> Interesting. Are there platforms where this is not available? I'd be
> >> pretty sure that some animals in the buildfarm would not like this
> >> suggestion but I'm saying it anyway. Perhaps we could even drop
> >> /dev/urandom?
> >
> > As far as I know macOS doesn't support getrandom() but supports
> > getentropy() instead. And an older glibc version might not support it.
> > It's supported since Linux 3.17 and glibc 2.25.
>
> getrandom() is Linux-specific, while getentropy() is specified by POSIX
> (since 2024). It was originally introduced by OpenBSD 5.6 in 2014, and
> was added to macOS 10.12 in 2016, glibc 2.25 (same as getrandom()) in
> 2017, musl 1.1.20 and FreeBSD 12.0 in 2018, and NetBSD 10.0 in 2024
>
> Sources:
>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.
<ilmari@ilmari.org> wrote:
>
> Masahiko Sawada <sawada.mshk@gmail.com> writes:
>
> > On Tue, Jul 22, 2025 at 12:13 AM Michael Paquier <michael@paquier.xyz> wrote:
> >>
> >> On Mon, Jul 21, 2025 at 11:43:35PM -0700, Masahiko Sawada wrote:
> >> > The patch supports the getrandom() function as a new source of
> >> > pg_strong_random(). The getrandom() function uses the same source as
> >> > the /dev/urandom device but it seems much faster than opening,
> >> > reading, and closing /dev/urandom. Here is the execution time of
> >> > generating 1 million UUIDv4 data measured on my environment:
> >> >
> >> > HEAD(/dev/urandom): 1863.064 ms
> >> > Patched(getrandom()): 516.627 ms
> >>
> >> Interesting. Are there platforms where this is not available? I'd be
> >> pretty sure that some animals in the buildfarm would not like this
> >> suggestion but I'm saying it anyway. Perhaps we could even drop
> >> /dev/urandom?
> >
> > As far as I know macOS doesn't support getrandom() but supports
> > getentropy() instead. And an older glibc version might not support it.
> > It's supported since Linux 3.17 and glibc 2.25.
>
> getrandom() is Linux-specific, while getentropy() is specified by POSIX
> (since 2024). It was originally introduced by OpenBSD 5.6 in 2014, and
> was added to macOS 10.12 in 2016, glibc 2.25 (same as getrandom()) in
> 2017, musl 1.1.20 and FreeBSD 12.0 in 2018, and NetBSD 10.0 in 2024
>
> Sources:
>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.
The
getentropy() function has a limitation of generating a maximum of 256 bytes of entropy per call and is not supported on Windows platforms. For cryptographic operations that require large buffers of high-quality randomness efficiently, it's not recommended to use getentropy(). In Postgres it’s common to see the SQL random() function used to generate a random number, but it’s a pseudo-random number generator, and not suitable for cases where real randomness is required critical. Postgres also provides a way of getting secure random numbers as well, but only through the use of the pgcrypto extension, which makes gen_random_bytes available. Pulling pgcrypto into ... brandur.org |
Thanks
Regards
Dinesh Nair
From: Masahiko Sawada <sawada.mshk@gmail.com>
Sent: Wednesday, July 23, 2025 12:02 AM
To: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Cc: Michael Paquier <michael@paquier.xyz>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Support getrandom() for pg_strong_random() source
Sent: Wednesday, July 23, 2025 12:02 AM
To: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Cc: Michael Paquier <michael@paquier.xyz>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Support getrandom() for pg_strong_random() source
Caution: This email was sent from an external source. Please verify the sender’s identity before clicking links or opening attachments.
On Tue, Jul 22, 2025 at 4:12 AM Dagfinn Ilmari Mannsåker
<ilmari@ilmari.org> wrote:
>
> Masahiko Sawada <sawada.mshk@gmail.com> writes:
>
> > On Tue, Jul 22, 2025 at 12:13 AM Michael Paquier <michael@paquier.xyz> wrote:
> >>
> >> On Mon, Jul 21, 2025 at 11:43:35PM -0700, Masahiko Sawada wrote:
> >> > The patch supports the getrandom() function as a new source of
> >> > pg_strong_random(). The getrandom() function uses the same source as
> >> > the /dev/urandom device but it seems much faster than opening,
> >> > reading, and closing /dev/urandom. Here is the execution time of
> >> > generating 1 million UUIDv4 data measured on my environment:
> >> >
> >> > HEAD(/dev/urandom): 1863.064 ms
> >> > Patched(getrandom()): 516.627 ms
> >>
> >> Interesting. Are there platforms where this is not available? I'd be
> >> pretty sure that some animals in the buildfarm would not like this
> >> suggestion but I'm saying it anyway. Perhaps we could even drop
> >> /dev/urandom?
> >
> > As far as I know macOS doesn't support getrandom() but supports
> > getentropy() instead. And an older glibc version might not support it.
> > It's supported since Linux 3.17 and glibc 2.25.
>
> getrandom() is Linux-specific, while getentropy() is specified by POSIX
> (since 2024). It was originally introduced by OpenBSD 5.6 in 2014, and
> was added to macOS 10.12 in 2016, glibc 2.25 (same as getrandom()) in
> 2017, musl 1.1.20 and FreeBSD 12.0 in 2018, and NetBSD 10.0 in 2024
>
> Sources:
>
> https://ind01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F9799919799%2Ffunctions%2Fgetentropy.html&data=05%7C02%7Cdinesh_nair%40iitmpravartak.net%7C6063a2ac8d4f45e1a74808ddc94e2e4e%7C3e964837c2384683915549f4ec04f8e9%7C0%7C0%7C638888059824005298%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=C5abb70MrRMb8YrRpFZreelrwfXgKtxWYNWvEc3oPFg%3D&reserved=0
> https://ind01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdotat.at%2F%40%2F2024-10-01-getentropy.html&data=05%7C02%7Cdinesh_nair%40iitmpravartak.net%7C6063a2ac8d4f45e1a74808ddc94e2e4e%7C3e964837c2384683915549f4ec04f8e9%7C0%7C0%7C638888059824035506%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RwqnnTVGURh7kw31OLW0kRUu%2BCUVVRlt%2Fx9FDDesb58%3D&reserved=0
>
> So I think it's more worthwhile to add support for getentropy() than
> getrandom().
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.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://ind01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faws.amazon.com%2F&data=05%7C02%7Cdinesh_nair%40iitmpravartak.net%7C6063a2ac8d4f45e1a74808ddc94e2e4e%7C3e964837c2384683915549f4ec04f8e9%7C0%7C0%7C638888059824052980%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NNEQNe%2Fibr6VRZAmBPWTy6r5J4pH2yza4PVGA4E9LO4%3D&reserved=0
On Tue, Jul 22, 2025 at 4:12 AM Dagfinn Ilmari Mannsåker
<ilmari@ilmari.org> wrote:
>
> Masahiko Sawada <sawada.mshk@gmail.com> writes:
>
> > On Tue, Jul 22, 2025 at 12:13 AM Michael Paquier <michael@paquier.xyz> wrote:
> >>
> >> On Mon, Jul 21, 2025 at 11:43:35PM -0700, Masahiko Sawada wrote:
> >> > The patch supports the getrandom() function as a new source of
> >> > pg_strong_random(). The getrandom() function uses the same source as
> >> > the /dev/urandom device but it seems much faster than opening,
> >> > reading, and closing /dev/urandom. Here is the execution time of
> >> > generating 1 million UUIDv4 data measured on my environment:
> >> >
> >> > HEAD(/dev/urandom): 1863.064 ms
> >> > Patched(getrandom()): 516.627 ms
> >>
> >> Interesting. Are there platforms where this is not available? I'd be
> >> pretty sure that some animals in the buildfarm would not like this
> >> suggestion but I'm saying it anyway. Perhaps we could even drop
> >> /dev/urandom?
> >
> > As far as I know macOS doesn't support getrandom() but supports
> > getentropy() instead. And an older glibc version might not support it.
> > It's supported since Linux 3.17 and glibc 2.25.
>
> getrandom() is Linux-specific, while getentropy() is specified by POSIX
> (since 2024). It was originally introduced by OpenBSD 5.6 in 2014, and
> was added to macOS 10.12 in 2016, glibc 2.25 (same as getrandom()) in
> 2017, musl 1.1.20 and FreeBSD 12.0 in 2018, and NetBSD 10.0 in 2024
>
> Sources:
>
> https://ind01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F9799919799%2Ffunctions%2Fgetentropy.html&data=05%7C02%7Cdinesh_nair%40iitmpravartak.net%7C6063a2ac8d4f45e1a74808ddc94e2e4e%7C3e964837c2384683915549f4ec04f8e9%7C0%7C0%7C638888059824005298%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=C5abb70MrRMb8YrRpFZreelrwfXgKtxWYNWvEc3oPFg%3D&reserved=0
> https://ind01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdotat.at%2F%40%2F2024-10-01-getentropy.html&data=05%7C02%7Cdinesh_nair%40iitmpravartak.net%7C6063a2ac8d4f45e1a74808ddc94e2e4e%7C3e964837c2384683915549f4ec04f8e9%7C0%7C0%7C638888059824035506%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RwqnnTVGURh7kw31OLW0kRUu%2BCUVVRlt%2Fx9FDDesb58%3D&reserved=0
>
> So I think it's more worthwhile to add support for getentropy() than
> getrandom().
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.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://ind01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faws.amazon.com%2F&data=05%7C02%7Cdinesh_nair%40iitmpravartak.net%7C6063a2ac8d4f45e1a74808ddc94e2e4e%7C3e964837c2384683915549f4ec04f8e9%7C0%7C0%7C638888059824052980%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NNEQNe%2Fibr6VRZAmBPWTy6r5J4pH2yza4PVGA4E9LO4%3D&reserved=0
pgsql-hackers by date: