Re: Support getrandom() for pg_strong_random() source

Поиск
Список
Период
Сортировка
От Jacob Champion
Тема Re: Support getrandom() for pg_strong_random() source
Дата
Msg-id CAOYmi+notAgUfhOgxP+yN40KYnp6M78fNUgSJY_tt-oihVkR1Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support getrandom() for pg_strong_random() source  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: Support getrandom() for pg_strong_random() source
Список pgsql-hackers
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?

Thanks,
--Jacob



В списке pgsql-hackers по дате отправления: