lkml.org 
[lkml]   [2008]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] drivers/net: remove network drivers' last few uses ofIRQF_SAMPLE_RANDOM
    Date

    ----- 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



    \
     
     \ /
      Last update: 2008-05-18 08:47    [W:4.358 / U:0.388 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site