Re: regarding the changes to kernel entropy gathering

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Mon, 5 Apr 2021 01:16:56 +0000 (UTC)
> From: RVP <rvp%SDF.ORG@localhost>
> 
> Then, the issue here is one of predictability. NetBSD doesn't want,
> for extremely valid reason, to incorporate any perturbation sources
> which have been pooh-poohed in the technical literature.

Why do you say that?  We do incorporate many sources that are not
well-studied -- every keystroke, for example, and the CPU cycle
counter at the time of the keystroke, affects the output of
/dev/urandom.

We just don't _count_ these sources for the purpose of detecting and
reporting the potential security problem of low entropy, because we
don't have a good model by which we can confidently claim they are
actually unpredictable to an adversary.

> Or, perhaps statistical tests of the raw in-kernel sources will
> demonstrate exactly why things like timing jitter have been
> pooh-poohed in the literature?

What do you mean by `things like timing jitter have been pooh-poohed
in the literature'?  Timing jitter in ring oscillators arising from
thermal noise in the silicon is the main source of entropy in most
on-die hardware RNGs on the market that I'm aware of.  This design is
reasonably well-studied in the literature.

We even try to use something like it by default in NetBSD when nothing
else is available -- we use the periodic hardclock interrupt timer to
sample the CPU cycle counter, in the hope that these clocks are driven
by independent oscillators with some timing jitter.

However, this is a generic mechanism that works on any machine -- and
on some machines, there is no CPU cycle counter so it might fall back
to using the hardclock timer as a substitute, defeating the purpose.
And even if there is a CPU cycle counter, it might be clocked by the
same oscillator as the hardclock timer, &c.  So we conservatively
count the hardclock entropy source as having zero entropy.