Re: Support getrandom() for pg_strong_random() source

On Mon, Sep 29, 2025 at 11:01 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Mon, Sep 29, 2025 at 03:15:37PM -0700, Jacob Champion wrote:
> > I'm wary of letting unprivileged users switch this implementation. I
> > think our developers should be allowed to treat the user as an
> > adversary when developing features on top of pg_strong_random(), and
> > it doesn't make sense for an adversary to control properties of your
> > CSPRNG. I'm also worried that allowing users to change the FIPS
> > properties of their systems could lead to compliance headaches for
> > some DBAs, but maybe somebody knows a reason why that wouldn't be a
> > concern in practice.
>
> I'm pretty sure that all cloud vendors would face this dilemma, and
> another thing that I suspect it that they would restrict entirely the
> access to this GUC.
>
> > But if only a superuser can change this, I'm not sure that it's going
> > to fit your use case anymore. Which probably brings the conversation
> > back to Daniel's note upthread -- is it worth the cost to expose this
> > as a runtime knob?
>
> I don't think we should expose that as a runtime-updatable parameter.

I agree that it should not be exposed as a runtime parameter.

> Even for UUIDs, I am reading the RFC as "more entropy the better" and
> I would choose entropy over performance every single day, because it's
> a no brainer if you care about cryptography, especially if this option
> enforces which source to use for for *all* code paths that want random
> bytes. So there is no deal about performance here, at least IMHO.

I'm still studying this area but is there any difference in entropy
between random numbers generated by getrandom() and OpenSSL's
RAND_bytes() in terms of entropy? The RFC says "Implementations SHOULD
utilize a cryptographically secure pseudorandom number generator
(CSPRNG) to provide values that are both difficult to predict
("unguessable") and have a low likelihood of collision ("unique")."
and IIUC getrandom() generates random numbers from the kernel's CSPRNG
module.

>
> Even as a superuser parameter, I'm having cold feet with this
> prospect. There are two aspects not discussed on this thread that
> could justify a PGC_POSTMASTER:
> - Testing, by being able to switch from one source to the other,
> providing more coverage with external libraries, useful for the
> buildfarm.
> - Insurance policy against vendor and library bugs. By switching to a
> different source with an existing build, it is possible to redirect
> the source of a bug somewhere else. It was also one of the reasons
> behind the GUCs that control the SSL protocol versions, where we
> wanted to bypass some versions. With TLSv3, this is less an issue
> these days, compared to SSLv1/2, still the argument applied when the
> SSL protocol GUCs were added.

Interesting points. If we can provide a knob as a GUC, I agree that it
should be a PGC_POSTMASTER parameter.

Regards,

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