Message-ID: <10a001c8b8b2$28afd2c0$f9b5a8c0@pii350>
Date:	Sun, 18 May 2008 08:41:10 +0200
From:	"Gilles Espinasse" <g.esp@...e.fr>
To:	"Adrian Bunk" <bunk@...nel.org>
Cc:	<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drivers/net: remove network drivers' last few uses ofIRQF_SAMPLE_RANDOM


----- Original Message ----- 
From: "Adrian Bunk" <bunk@...nel.org>
To: "Gilles Espinasse" <g.esp@...e.fr>
Cc: <netdev@...r.kernel.org>; <linux-kernel@...r.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists