From: Ben Hutchings <bhutchings@solarflare.com>
To: Javier Martinez Canillas <martinez.javier@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
David Miller <davem@davemloft.net>,
Dan Carpenter <error27@gmail.com>,
netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 2/2 v2] tg3: Don't use IRQF_SAMPLE_RANDOM
Date: Mon, 28 Mar 2011 18:20:22 +0100 [thread overview]
Message-ID: <1301332822.2716.12.camel@bwh-desktop> (raw)
In-Reply-To: <AANLkTi=Qkf2qn6nQ-6AXE8LtFSD++=eZRxa6ND6KPsk1@mail.gmail.com>
On Mon, 2011-03-28 at 17:46 +0200, Javier Martinez Canillas wrote:
> On Mon, Mar 28, 2011 at 2:25 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > 1) We dont believe its Janitor material ;)
> >
> > http://thread.gmane.org/gmane.linux.kernel/680723
> >
> > http://kerneltrap.org/mailarchive/linux-netdev/2009/4/6/5417754
> >
>
> I wasn't aware of this discussion. In one hand network drivers are not
> a good source of entropy because they can be controlled externally,
> but in embedded systems with only network cards (no video, audio,
> keyboard, etc) the only source of entropy they have is their network
> cards (at the kernel level i.e: not using EGD to feed /dev/random).
It may be the only source of entropy, but given how poor a source it is
these drivers are basically telling sweet little lies to the kernel and
the applications that demand real random numbers.
This also applies to many servers just as much as embedded systems.
As you acknowledge, these systems can still get entropy using the EGD
protocol over a secure channel. (Or an entropy sampling device such as
the Entropy Key.)
> Yes this definitely is not janitor material :)
>
> I just sent the patch because I saw IRQF_SAMPLE_RANDOM in
> Documentation/feature-removal-schedule.txt. I can resend a patch
> removing the macro in the remaining network cards if the decision is
> to remove IRQF_SAMPLE_RANDOM.
It's not my call, but I would support it.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2011-03-28 17:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-28 12:15 [PATCH 2/2 v2] tg3: Don't use IRQF_SAMPLE_RANDOM Javier Martinez Canillas
2011-03-28 12:25 ` Eric Dumazet
2011-03-28 15:46 ` Javier Martinez Canillas
2011-03-28 17:20 ` Ben Hutchings [this message]
2011-03-28 20:08 ` Florian Fainelli
2011-03-28 20:32 ` Ben Hutchings
2011-03-28 23:53 ` David Miller
2011-03-29 11:26 ` Javier Martinez Canillas
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=1301332822.2716.12.camel@bwh-desktop \
--to=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=error27@gmail.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=martinez.javier@gmail.com \
--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).