Re: OpenSSL randomness seeding - Mailing list pgsql-hackers

From Noah Misch
Subject Re: OpenSSL randomness seeding
Date
Msg-id 20200722050020.GA661537@rfd.leadboat.com
Whole thread Raw
In response to OpenSSL randomness seeding  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: OpenSSL randomness seeding  (Michael Paquier <michael@paquier.xyz>)
Re: OpenSSL randomness seeding  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
On Tue, Jul 21, 2020 at 02:13:32PM +0200, Daniel Gustafsson wrote:
> The silver lining here is that while OpenSSL nooped RAND_cleanup, they also
> changed what is mixed into seeding so we are still not sharing a sequence.  To
> fix this, changing the RAND_cleanup call to RAND_poll should be enough to
> ensure re-seeding after forking across all supported OpenSSL versions.  Patch
> 0001 implements this along with a comment referencing when it can be removed
> (which most likely won't be for quite some time).
> 
> Another thing that stood out when reviewing this code is that we optimize for
> RAND_poll failing in pg_strong_random, when we already have RAND_status
> checking for a sufficiently seeded RNG for us.  ISTM that we can simplify the
> code by letting RAND_status do the work as per 0002, and also (while unlikely)
> survive any transient failures in RAND_poll by allowing all the retries we've
> defined for the loop.

> Thoughts on these?

These look good.  I'll push them on Saturday or later.  I wondered whether to
do both RAND_cleanup() and RAND_poll(), to purge all traces of the old seed on
versions supporting both.  Since that would strictly (albeit negligibly)
increase seed predictability, I like your decision here.

Do you happen to know how OpenSSL 1.1.1 changed its reaction to forks in order
to make the RAND_poll() superfluous?  (No need to research it if you don't.)



pgsql-hackers by date:

Previous
From: Antonin Houska
Date:
Subject: Re: xl_heap_header alignment?
Next
From: David Rowley
Date:
Subject: Re: Parallel Seq Scan vs kernel read ahead