Re: random() (was Re: New GUC to sample log queries)

On Sat, Dec 29, 2018 at 1:37 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
> > Looking at this, I seem to remember that we considered doing exactly this
> > awhile ago, but refrained because there was concern about depleting the
> > system's reserve of entropy if we have a high backend spawn rate, and it
> > didn't seem like there was a security reason to insist on unpredictable
> > random() results. However, the log-sampling patch destroys the latter
> > argument. As for the former argument, I'm not sure how big a deal that
> > really is. Presumably, the act of spawning a backend would itself
> > contribute some more entropy to the pool (particularly if a network
> > connection is involved), so the depletion problem might be fictitious
> > in the first place. Also, a few references I consulted, such as the
> > Linux urandom(4) man page, suggest that even in a depleted-entropy
> > state the results of reading /dev/urandom should be random enough
> > for all but the very strictest security requirements.
>
> I did some experimentation, watching /proc/sys/kernel/random/entropy_avail
> while continuously spawning backends, and I can't see any difference in
> behavior with or without this patch. If there is any effect at all, it's
> completely swamped by other noise (and there's a lot of noise, even on a
> machine that's idle).
>
> Also, further googling says there's a pretty sizable body of opinion that
> Linux's available-entropy calculation is bogus anyway: once the system's
> acquired a reasonable amount of entropy, no amount of reading from
> /dev/urandom will cause the randomness of the results to decrease.
> So there's no reason to be concerned about whether we're reading it
> "too much".

I was going to suggest that we might be able to use a single
not-visible-to-users number that is mixed into the existing recipe, so
that we only ever read urandom once for the cluster. But it sounds
like it's not a problem, and it's probably better to just pass the
whole problem over to the OS.

--
Thomas Munro
http://www.enterprisedb.com