From: "Gilles Espinasse" <g.esp@free.fr>
To: "Adrian Bunk" <bunk@kernel.org>
Cc: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drivers/net: remove network drivers' last few uses ofIRQF_SAMPLE_RANDOM
Date: Sun, 18 May 2008 08:41:10 +0200 [thread overview]
Message-ID: <10a001c8b8b2$28afd2c0$f9b5a8c0@pii350> (raw)
In-Reply-To: 20080517220258.GC8140@cs181133002.pp.htv.fi
----- Original Message -----
From: "Adrian Bunk" <bunk@kernel.org>
To: "Gilles Espinasse" <g.esp@free.fr>
Cc: <netdev@vger.kernel.org>; <linux-kernel@vger.kernel.org>
Sent: Sunday, May 18, 2008 12:02 AM
Subject: Re: [PATCH] drivers/net: remove network drivers' last few uses
ofIRQF_SAMPLE_RANDOM
> On Fri, May 16, 2008 at 10:08:29PM +0200, Gilles Espinasse wrote:
> >
> > That's funny
> > It does look to disturb some kernel developper that ethernet may be
sniffed
> > to feed a RNG
> > even that could be very hard to reach any effective result in the case
of a
> > machine splitting different network segments.
> >
> > In the same time, it does not disturb openssl developpers to include non
> > initialised memory that may or may not be predictable to feed a RNG.
> > http://marc.info/?l=openssl-dev&m=121095151003011&w=2
>
> Why should it disturb them?
>
> As is explained in the email you quote it cannot make the RNG
> output worse.
>
Yes that's the whole point.
Why remove IRQF_SAMPLE_RANDOM if "it cannot make the RNG output worse."
We should not care if network traffic can be sniffed in some configurations
(plus sniffing could be very unlikely in some others).
There is some objections that I understand (less IRQ with NAPI or less IRQ
with more network traffic). But there is still the problem to have other
entropy supplier for any existing machines without hw_random chip.
For the few machines with a supported hw_random chip, rng-tools should do
the job (and far better)
I look at other possible entropy solutions proposed by Jeff Garzic
http://sourceforge.net/projects/egd
That's for system without /dev/random and linux has /dev/random.
http://sourceforge.net/projects/prngd
README say
"- If you have a UNIX version providing /dev/urandom or /dev/random you
probably won't need PRNGD at all."
So I didn't find an operational replacement solution yet now.
I don't say something is not doable re-using parts of egd or prngd to feed
the entropy pool.
I had experiences with the entropy pool empty since 2.6.12.
I am running headless machines to compile with not much other activities
sometime.
On a headless machine running 2.6.11 kernel, openswan-1.0.10 was compiling
fine.
On that same machine upgraded to 2.6.12 vanillia kernel, package compilation
will wait I feed
the entropy pool by some actions (keyboard/console) during ipsec.secrets
generation.
Failed instruction was rsasigkey --verbose 2192
Problem was caused by the changes to feed the entropy pool on 2.6.12
2.6.25 fail the same way on that machine.
Each time any source to feed the entropy pool is removed, /dev/random
situation is always worst and DOS may happen.
I understand IRQF_SAMPLE_RANDOM on a network card may be not the GREAT
solution.
In fact, this machine use via_rhine nic driver that does not have
SAMPLE_RANDOM collection even in 2.6.11 (and there not much traffic on this
machine when packages cache is up to date).
Are network drivers better without SAMPLE_RANDOM?
My understanding of openssl developper answer is same as yours :
"it cannot make the RNG output worse."
So why remove SAMPLE_RANDOM on network cards today if there is no
replacement solution ready for x% of machines running linux actually?
How many SAMPLE_RANDOM sources remain that have a chance to be run on the
average machine running linux?
Gilles
next prev parent reply other threads:[~2008-05-18 6:44 UTC|newest]
Thread overview: 91+ 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
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-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
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 ` Gilles Espinasse [this message]
2008-05-18 9:54 ` [PATCH] drivers/net: remove network drivers' last few uses ofIRQF_SAMPLE_RANDOM 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-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='10a001c8b8b2$28afd2c0$f9b5a8c0@pii350' \
--to=g.esp@free.fr \
--cc=bunk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).