[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <482D99DC.7040501@garzik.org>
Date: Fri, 16 May 2008 10:27:40 -0400
From: Jeff Garzik <jeff@...zik.org>
To: Will Newton <will.newton@...il.com>
CC: Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
"Kok, Auke" <auke-jan.h.kok@...el.com>,
Rick Jones <rick.jones2@...com>,
"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Chris Peterson <cpeterso@...terso.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drivers/net: remove network drivers' last few uses of
IRQF_SAMPLE_RANDOM
Will Newton wrote:
> On Fri, May 16, 2008 at 2:40 PM, Jeff Garzik <jeff@...zik.org> wrote:
>> Lennart Sorensen wrote:
>>> On Thu, May 15, 2008 at 03:21:49PM -0400, Jeff Garzik wrote:
>>>> "no other form of entropy"? See examples in this thread.
>>> So where does one get entropy if not the ethernet adapter on many
>>> embedded systems? If you have no mouse, no keyboard, no hardware number
>>> generator, just ethernet ports and a serial console that usually
>>> receives no input. While ethernet might not be preferable if you have
>>> something else, sometimes you really don't have anything else.
>> Already answered in this thread... EGD illustrates how many sources of
>> entropy remain, even in the example you just gave.
>>
>> Further, you do not want to rely on entropy from a source that declines just
>> as network traffic increases.
>
> I don't know egd that well, but from a cursory look it gets data from
> such things as w or last (wtmp) which is static on most embedded
> boxes.
Inevitably some of the local-machine entropy sources will be static or
externally influenced. That's the whole point of using several. If
using one source was sufficient... we would just use that one and be
done with it. :)
The questions to ask are
* is this collective snapshot of local machine state sufficiently unique?
* is this local-machine state externally controllable within realistic
orders of complexity?
> It also uses netstat and snmp - surely this is at least as easy
> to manipulate as interrupt timings?
netstat reflects local machine state of all sockets, including local
ones, and including local details like tcp in-q and out-q. snmp can
query MIBs such as ethernet wire stats, gaining entropy from
pause/collision/etc. frame statistics.
A set of mitigated network interrupt events is far, far more predictable
and controllable than the collective state of a machine's network
sockets, or the electrical state of the ethernet LAN link.
For network-interrupt randomness to be subverted in some cases, one
might need only to increase overall network traffic to a certain level.
Jeff
--
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
Powered by blists - more mailing lists