Re: DSM segment handle generation in background workers

Noah Misch <noah@leadboat.com>

From: Noah Misch <noah@leadboat.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-11-14T07:52:18Z
Lists: pgsql-hackers
On Wed, Nov 14, 2018 at 08:22:42PM +1300, Thomas Munro wrote:
> 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?

You mentioned that you rewrote the algorithm because the new function had a
TimestampTz.  But the BackendRun() code, which it replaced, also had a
TimestampTz.  You can reuse the exact algorithm.  Is there a reason to change?


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().