Re: [PATCH] drivers/net: remove network drivers' last few uses ofIRQF_SAMPLE_RANDOM
From: Gilles Espinasse
Date: Sun May 18 2008 - 02:44:20 EST
----- Original Message -----
From: "Adrian Bunk" <bunk@xxxxxxxxxx>
To: "Gilles Espinasse" <g.esp@xxxxxxx>
Cc: <netdev@xxxxxxxxxxxxxxx>; <linux-kernel@xxxxxxxxxxxxxxx>
Sent: Sunday, May 18, 2008 12:02 AM
Subject: Re: [PATCH] drivers/net: remove network drivers' last few uses
> 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
> > to feed a RNG
> > even that could be very hard to reach any effective result in the case
> > 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
That's for system without /dev/random and linux has /dev/random.
"- 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
On a headless machine running 2.6.11 kernel, openswan-1.0.10 was compiling
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
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
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?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/