From: Andi Kleen <andi@firstfloor.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jeff Garzik <jeff@garzik.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
"Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
Chris Peterson <cpeterso@cpeterso.com>,
tpmdd-devel@lists.sourceforge.net, tpm@selhorst.net,
Herbert Xu <herbert@gondor.apana.org.au>
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 [thread overview]
Message-ID: <482D5FC5.2070103@firstfloor.org> (raw)
In-Reply-To: <20080516105635.6cb1f505@core>
Alan Cox wrote:
> 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.
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
next prev parent reply other threads:[~2008-05-16 10:20 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-15 7:11 [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM Chris Peterson
2008-05-15 13:21 ` Alan Cox
2008-05-15 16:07 ` Brandeburg, Jesse
2008-05-15 16:39 ` Alan Cox
2008-05-15 18:14 ` Jeff Garzik
2008-05-15 18:47 ` Kok, Auke
2008-05-15 19:10 ` Jeff Garzik
2008-05-15 18:50 ` Rick Jones
2008-05-15 19:11 ` Jeff Garzik
2008-05-15 19:55 ` [PATCH] " Jeff Garzik
2008-05-16 0:27 ` Andi Kleen
2008-05-16 9:56 ` Alan Cox
2008-05-16 10:19 ` Andi Kleen [this message]
2008-05-16 12:12 ` Herbert Xu
2008-05-16 16:25 ` Andi Kleen
2008-05-17 1:01 ` Herbert Xu
2008-05-17 10:59 ` Andi Kleen
2008-05-17 19:54 ` Chris Peterson
2008-05-17 20:05 ` Arjan van de Ven
2008-05-18 10:13 ` Andi Kleen
2008-05-18 11:26 ` Theodore Tso
2008-05-18 12:57 ` Joe Korty
2008-05-18 17:53 ` Andi Kleen
2008-05-25 15:26 ` Glen Turner
2008-05-19 12:29 ` Benny Amorsen
2008-05-18 10:08 ` Andi Kleen
2008-05-22 9:28 ` Helge Hafting
2008-05-16 13:20 ` Adrian Bunk
2008-05-16 16:20 ` Andi Kleen
2008-05-16 19:47 ` David Miller
2008-05-16 23:28 ` Rick Jones
2008-05-15 18:04 ` Jeff Garzik
2008-05-15 18:17 ` Rick Jones
2008-05-15 18:31 ` Jeff Garzik
2008-05-15 18:47 ` Kok, Auke
2008-05-15 19:21 ` Jeff Garzik
2008-05-15 20:01 ` Chris Peterson
2008-05-15 20:16 ` Jeff Garzik
2008-05-15 20:39 ` Kok, Auke
2008-05-15 21:47 ` Theodore Tso
2008-05-15 21:58 ` Jeff Garzik
2008-05-15 22:29 ` Henrique de Moraes Holschuh
2008-05-15 22:44 ` Jeff Garzik
2008-05-15 23:02 ` Henrique de Moraes Holschuh
2008-05-15 23:36 ` Theodore Tso
2008-05-15 23:46 ` Henrique de Moraes Holschuh
2008-05-15 23:33 ` Theodore Tso
2008-05-15 23:58 ` Henrique de Moraes Holschuh
2008-05-16 13:21 ` Lennart Sorensen
2008-05-16 13:40 ` Jeff Garzik
2008-05-16 13:59 ` Will Newton
2008-05-16 14:15 ` Lennart Sorensen
2008-05-16 14:27 ` Jeff Garzik
2008-05-16 15:10 ` Alan Cox
2008-05-16 17:36 ` Lennart Sorensen
2008-05-16 18:11 ` Alan Cox
2008-05-16 18:40 ` Kok, Auke
2008-05-18 10:59 ` Matthias Andree
2008-05-16 18:41 ` Lennart Sorensen
2008-05-16 18:42 ` Lennart Sorensen
2008-05-16 20:04 ` Alan Cox
2008-05-16 20:39 ` Lennart Sorensen
2008-05-16 20:46 ` Alan Cox
2008-05-16 20:34 ` Benny Amorsen
2008-05-25 15:02 ` Glen Turner
2008-05-25 19:33 ` Benny Amorsen
2008-05-17 4:55 ` Chris Peterson
2008-05-25 15:09 ` Glen Turner
2008-05-25 23:27 ` Theodore Tso
2008-05-26 13:43 ` Alejandro Riveira Fernández
2008-05-26 15:14 ` Bill Fink
2008-05-26 21:07 ` Krzysztof Halasa
2008-05-26 21:52 ` Bill Fink
2008-05-26 22:11 ` Ben Hutchings
2008-05-27 16:44 ` Rick Jones
2008-05-30 19:50 ` Pavel Machek
[not found] ` <20080516191125.46 <20080525232712.GF5970@mit.edu>
2008-05-26 21:08 ` Gilles Espinasse
2008-05-25 14:55 ` Glen Turner
[not found] ` <482C8550 <20080516161029.44ded734@core>
2008-05-16 20:08 ` Gilles Espinasse
2008-05-17 22:02 ` Adrian Bunk
2008-05-18 6:41 ` [PATCH] drivers/net: remove network drivers' last few uses ofIRQF_SAMPLE_RANDOM Gilles Espinasse
2008-05-18 9:54 ` Alan Cox
2008-05-18 12:02 ` Adrian Bunk
2008-05-18 12:24 ` Theodore Tso
2008-05-18 14:43 ` Adrian Bunk
2008-05-15 21:55 ` [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM Adrian Bunk
2008-05-15 22:04 ` Jeff Garzik
2008-05-15 22:27 ` Theodore Tso
2008-05-15 22:13 ` Jesper Juhl
2008-05-15 22:34 ` Theodore Tso
2008-05-15 22:57 ` Jesper Juhl
2008-05-18 0:36 ` Matt Mackall
2008-05-18 11:03 ` Matthias Andree
2008-05-15 22:42 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=482D5FC5.2070103@firstfloor.org \
--to=andi@firstfloor.org \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cpeterso@cpeterso.com \
--cc=herbert@gondor.apana.org.au \
--cc=jeff@garzik.org \
--cc=jesse.brandeburg@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tpm@selhorst.net \
--cc=tpmdd-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox