Re: [PATCH] Kernel entropy rework

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Sun, 22 Dec 2019 01:27:58 +0000
> From: <Paul.Koning%dell.com@localhost>
> 
> > On Dec 21, 2019, at 5:08 PM, Taylor R Campbell <riastradh%NetBSD.org@localhost> wrote:
> >      - For (e.g.) keyboard interrupt and network packet timings, this
> >        is zero, because an adversary can cause events to happen with
> >        timing that leads to predictable samples entering the pool.
> 
> That seems overly pessimistic, depending on the timer resolution.
> If you have a CPU cycle timer, then it is perfectly reasonable to
> claim a bit or two of entropy, since an adversary doesn't have the
> ability to control the timing of those events to nanosecond
> accuracy, nor the ability to control internal processing delays
> (like memory cache misses) which introduce variability way in excess
> of a CPU cycle.

When I'm typing, there might be nonzero entropy in the cycle counts
between keystrokes on my 2.3 GHz laptop.  But I don't have a good
model, justified by physics, for the probability distribution on the
differences in cycle counts.  And I definitely don't have one that
works for all keyboards on all types of buses on all machines under
all typing styles by all adversaries, including my cat sleeping on my
keyboard.  Do you?

We can wave hands about cache misses, but adversaries often have a lot
of avenues for influencing the microarchitectural state of the CPU
via, e.g., network packets that trigger specific code paths.  So I'm
not willing to commit to higher entropy estimates for something that
was never designed to be unpredictable in the first place unless
there's a confidence-inspiring argument -- involving physics and
engineering of the hardware -- to justify it.

This may well be pessimistic.  It would be great if we could make
better promises to users -- but only if we can be honest in those
promises.  Right now we are trading honesty for expediency.  My hope
is that, for most users, everything else in this change and other
recent changes will render moot the motivation for that bargain in the
first place.


Of course, driver authors have also taken claims by various hardware
RNG vendors at face value:

- Sometimes they are at least backed up by design documents, like the
  Intel RDRAND/RDSEED.

- Sometimes they are backed up by external audits, like the VIA C3
  XSTORE RNG.

- Sometimes they are just opaque device registers or DMA commands and
  you have to do science on them yourself, like the Allwinner Sun8i
  Crypto Engine TRNG, which seems to have at most 1 bit of min-entropy
  for every 100 bits of data (and is currently disabled by default
  until I have a better idea of what to expect from it).

What can I honestly promise works?  Flip a coin 256 times and run
`echo httttthhthhhthhhtttt... >> /dev/random'; then the random seed
management of rndctl should take care of you for the foreseeable
future.  Of course, most users don't have the patience for that.
Fortunately, most users do not have Intel in their threat model; for
those users it is reasonable to rely on Intel RDRAND/RDSEED, for
instance.