Subject: Guidelines for hardware RNG drivers in NetBSD
To: None <firstname.lastname@example.org, email@example.com>
From: Thor Lancelot Simon <firstname.lastname@example.org>
Date: 12/05/2006 13:48:28
On Tue, Dec 05, 2006 at 05:59:48PM +0000, Christos Zoulas wrote:
> In article <email@example.com>, Yorick Hardy <firstname.lastname@example.org> wrote:
> >ID Quantique have a quantum random number generator
> > http://www.idquantique.com/products/quantis.htm
> >which includes drivers for FreeBSD.
> >I adapted the drivers for NetBSD:
> > http://issc.uj.ac.za/~yorick/quantis_netbsd.tar.bz2
> >Can anyone comment or make suggestions?
> >Can or should the driver support rnd(9)?
> I think that it should support rnd(9) look at the hifn7751 or the amdpm
> driver in sys/dev/pci.
> Also you should KNF the driver. The copyright in the common sources looks
> BSD'ish but the other files don't have any copyrights.
If you have design documentation for the RNG, pay careful attention to
what hifn7751.c does in order to ensure that the entropy estimate for
the kernel random pool is good -- it was rewritten from the Hifn design
docs with help from Hifn because it was clear that the original code was
not doing this right.
1) Many RNGs have a warm-up time before they produce the designed
amount of entropy per output bit. Don't feed bits into the
kernel pool until you know this time has passed.
2) Some RNGs do not actually guarantee that successive reads give
data that are actually represent different samples from whatever
means is used to digitize the underlying source (for example,
the hifn 7xx do not, because of a design mistake). If this
is the case, you must ensure that you do not sample them faster
than _they_ sample the random data. The workaround in the Hifn
driver is ugly, but sufficient (it would be more efficient to
wait, but waiting _between device reads_ in the callout is not
so easy to do).
3) With design documentation it is usually possible to determine a
worst-case estimate for bits of underlying source entropy per
output bit of the hardware generator. In this case, you want
to be sure that you feed the random pool enough generator
output at once to ensure that you can give it a valid estimate
of at least one bit -- see the value, and use, of
HIFN_RNG_BITSPER and note that if we fed the random pool less
than three bytes at a time, we'd be forced to estimate 0
entropy -- not good.
4) Be careful, with regard to some cryptographic hardware now on
the market at least, that what you are feeding the random pool
is not actually the *output* of a cryptographic PRNG keyed from
a source of dubious quality (this is the case for a number of
'FIPS compliant' RNGs integrated into currently available