From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Fri, 16 May 2008 10:56:35 +0100

quoted text
> On Fri, 16 May 2008 02:27:36 +0200
> Andi Kleen <andi@firstfloor.org> wrote:
> 
> > Jeff Garzik <jeff@garzik.org> writes:
> > >
> > > A hw_random driver for TPM still needs to (a) parse the TPM header for
> > > return code, (b) extract RNG bytes out at offset 14, and (c) figure
> > > out some way to get a tpm_chip pointer.
> > 
> > (d) auto feed the information into random.c. Otherwise it'll be useless
> > for most people.
> 
> No - you don't want to do FIPS randomness verification in kernel space.
> Plus all the other random generator inputs are done via the user space
> daemon as they should be.

This does remind me of a deficiency in the current hwrng driver layer
that I noticed while working on the Niagara2 RNG driver.

If the device allows tweaking of settings (selecting different voltage
oscillators per entropy source in my case) we really need some way to
test the randomness generated by different setting so that we can make
an optimal choice.

One common scheme is to compute the Renyi entropy for blocks of random
data using the various settings, something else we don't want in the
kernel.

So we would need some kind of interface so that userland could handle
something like that.  Something like:

1) Export number of possible configurations to userspace
2) Allow userspace to simply iterate over the configurations,
   something as simple as just specifying an integer index
   in the range 0 to num_configs

Then userspace can do randomness analysis of the different configurations
however it and the user's choosen policy dictate.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html