Messages in this thread | | | Date | Fri, 16 May 2008 12:47:11 -0700 (PDT) | Subject | Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM | From | David Miller <> |
| |
From: Alan Cox <alan@lxorguk.ukuu.org.uk> Date: Fri, 16 May 2008 10:56:35 +0100
> 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.
| |