Re: DSM segment handle generation in background workers

Thomas Munro <thomas.munro@enterprisedb.com>

From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Noah Misch <noah@leadboat.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-11-14T07:22:42Z
Lists: pgsql-hackers

Attachments

On Wed, Nov 14, 2018 at 6:34 PM Noah Misch <noah@leadboat.com> wrote:
> On Wed, Nov 14, 2018 at 05:50:26PM +1300, Thomas Munro wrote:
> > On Wed, Nov 14, 2018 at 3:24 PM Noah Misch <noah@leadboat.com> wrote:
> > > What counts is the ease of predicting a complete seed.  HEAD's algorithm has
> > > ~13 trivially-predictable bits, and the algorithm that stood in BackendRun()
> > > from 98c5065 until 197e4af had no such bits.  You're right that the other 19
> > > bits are harder to predict than any given 19 bits under the old algorithm, but
> > > the complete seed remains more predictable than it was before 197e4af.
> >
> > However we mix them, given that the source code is well known, isn't
> > an attacker's job really to predict the time and pid, two not
> > especially well guarded secrets?
>
> True.  Better to frame the issue as uniform distribution of seed, not
> unpredictability of seed selection.

What do you think about the attached?

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

Commits

  1. Increase the number of possible random seeds per time period.

  2. Refactor pid, random seed and start time initialization.

  3. Increase the number of different values used when seeding random().