Re: Changes to make /dev/*random better sooner

[David Laight <david%l8s.co.uk@localhost>]

On Thu, Apr 10, 2014 at 04:14:46PM -0700, Dennis Ferguson wrote:
> 
> On 10 Apr, 2014, at 05:34 , Thor Lancelot Simon <tls%panix.com@localhost> 
> wrote:
> 
> > On Wed, Apr 09, 2014 at 04:36:26PM -0700, Dennis Ferguson wrote:
> >> 
> >> I'd really like to understand what problem is fixed by this.  It
> >> seems to make the code more expensive (significantly so since it
> >> precludes using timestamps in their cheapest-to-obtain form) but
> >> I'm missing the benefit this cost pays for.
> > 
> > It's no more expensive to sample a 64-bit than a 32-bit cycle counter,
> > if you have both.  Where do we have access to only a 32-bit cycle
> > counter?  I admit that the problem exists in theory.  I am not so sure
> > at all that it exists in practice.
> 
> 32 bit ARM processors have a 32-bit CPU cycle counter, when they
> have one.  PowerPC processors have a 64-bit counter but the 32-bit
> instruction set provides no way to get an atomic sample of all 64
> bits.  It requires three "special" instructions followed by a check
> and a possible repeat of the three instructions to get a consistent
> sample, which makes that significantly less useful for accurate event
> timing than the single atomic instruction which obtains the low order
> 32 bits alone.  I know i386, and 32-bit sparc running on a 64-bit
> processor, can get atomic samples of 64 bits of cycle counter from
> the 32-bit instruction set but I think those are exceptions rather
> than rules.

For the purposes of obtaining entropy it doesn't matter if the high
and low parts don't match.
Is there likely to be interesting entropy in the high bits anyway
- certainly not more than once.

Also, having read high, low, high and found that the two 'high'
values differ, take the latter high bits and zero the low bits.
The value returned occurred while the counter was being read -
so is a valid return value.

        David

-- 
David Laight: david%l8s.co.uk@localhost