netdev - Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 May 2008 12:47:11 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	alan@...rguk.ukuu.org.uk
Cc:	andi@...stfloor.org, jeff@...zik.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	jesse.brandeburg@...el.com, cpeterso@...terso.com,
	tpmdd-devel@...ts.sourceforge.net, tpm@...horst.net,
	herbert@...dor.apana.org.au
Subject: Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last
 few uses of IRQF_SAMPLE_RANDOM

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

> On Fri, 16 May 2008 02:27:36 +0200
> Andi Kleen <andi@...stfloor.org> wrote:
> 
> > Jeff Garzik <jeff@...zik.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html