netdev - Re: [PATCH 2/2 v2] tg3: Don't use IRQF_SAMPLE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1301344344.27727.15.camel@bwh-desktop>
Date:	Mon, 28 Mar 2011 21:32:24 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Florian Fainelli <ffainelli@...ebox.fr>
Cc:	Javier Martinez Canillas <martinez.javier@...il.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>,
	Dan Carpenter <error27@...il.com>, netdev@...r.kernel.org,
	kernel-janitors@...r.kernel.org
Subject: Re: [PATCH 2/2 v2] tg3: Don't use IRQF_SAMPLE_RANDOM

On Mon, 2011-03-28 at 22:08 +0200, Florian Fainelli wrote:
> Hello,
> 
> On Monday 28 March 2011 19:20:22 Ben Hutchings wrote:
> > 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@...il.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.
> 
> Indeed, this is the reason why bcm63xx_enet.c for instance contributes to the 
> general entropy of the system, because it is used on MIPS based ADSL routers 
> where we have little or no other source of entropy.
> 
> Still even poor entropy is better than none on such devices imho.
[...]

Well, only if it's treated as such.

add_timer_randomness() does try to measure how much entropy it's getting
from the time, which should address the problem of interrupt moderation
causing predictable interrupts.  However I strongly suspect that its
tests cannot protect against deliberately timed packets, particularly if
get_cycles() has low resolution.  (On MIPS, get_cycles() always returns
0, although the comment before suggests that this is possible to do
better.)

I notice that there is an internal option 'dont_count_entropy' which
would allow interrupts to add entropy without it increasing the
estimated total entropy in the pool.  If that was set for network
interrupts, they could be used to improve the quality of /dev/urandom,
get_random_bits(), etc. without compromising applications that demand
real randomness.

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.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html