|From:||Andi Kleen <andi-AT-firstfloor.org>|
|To:||Alan Cox <alan-AT-lxorguk.ukuu.org.uk>|
|Subject:||Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM|
|Date:||Fri, 16 May 2008 12:19:49 +0200|
|Cc:||Jeff Garzik <jeff-AT-garzik.org>, netdev-AT-vger.kernel.org, linux-kernel-AT-vger.kernel.org, Andrew Morton <akpm-AT-linux-foundation.org>, "Brandeburg, Jesse" <jesse.brandeburg-AT-intel.com>, Chris Peterson <cpeterso-AT-cpeterso.com>, tpmdd-devel-AT-lists.sourceforge.net, tpm-AT-selhorst.net, Herbert Xu <herbert-AT-gondor.apana.org.au>|
Alan Cox wrote: > On Fri, 16 May 2008 02:27:36 +0200 > Andi Kleen <email@example.com> wrote: > >> Jeff Garzik <firstname.lastname@example.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. Just think a little bit: system has no randomness source except the hardware RNG. you do your strange randomness verification. if it fails what do you do? You don't feed anything into your entropy pool and all your random output is predictable (just boot time) If you add anything predictable from another source it's still predictable, no difference. Also in general what happens in the hypothetical case that your random generator e.g. generates all zeros (which is very unlikely but let's assume it): your entropy doesn't get significantly worse than it was before. Previously it was just seeded with the boot time (or other sources) and now you're adding some zeroes. The output is still as random as the previous state. While that changes the state of the entropy pool it doesn't make it any easier to predict. The only problem you got from possible bogus input is that the entropy counts will be wrong, but in my experience nearly all programs use /dev/urandom anyways because /dev/random is just a DoS waiting to happen and user space programmers know that. Basically with this insisting on FIPS you're violating the strong variant of Steinbach's rule: not only "never test for an error condition you don't know how to handle", but "never test for an error condition you can't handle" Also why do you not trust your random generator but trust your CPU to correctly execute the cryptographic algorithm? Not trusting your own hardware doesn't really make any sense here. > Plus all the other random generator inputs are done via the user space > daemon as they should be. Yes and which makes them about useless because distros don't run that daemon by default so users don't get the feature. Besides it's all not needed anyways because the FIPS verification is pointless. -Andi -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html
Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds