In debugging why my (unloaded) IMAP server takes many seconds
to open folders, I discovered what looks like a problem
in 2.4's feeding of entropy into /dev/random. When there
is insufficient entropy in the random number generator,
reading from /dev/random blocks for several seconds. /dev/random
is used (correctly) for crytographic key verification.
Entropy comes from 4 sources it seems: Keyboard, Mouse, Disk I/O
and IRQs.
The machine in question is locked in a data center (can't be
the only one) and thus sees none of the former two. IDE Entropy
comes from executed IDE commands. The disk is physically largely
inactive due to caching. But there's plenty of network traffic
which should generate IRQs.
However, only 3 drivers in drivers/net actually set
SA_SAMPLE_RANDOM when calling request_irq(). I believe
all of them should. And indeed this fixed the problem for
me using an eepro100().
The following patch fixes eepro100.c - others can be
patched similarly.
--
Alex Bligh
/usr/src/linux# diff -C3 drivers/net/eepro100.c{.keep,}
*** drivers/net/eepro100.c.keep Tue Feb 13 21:15:05 2001
--- drivers/net/eepro100.c Sun Apr 8 22:17:00 2001
***************
*** 923,929 ****
sp->in_interrupt = 0;
/* .. we can safely take handler calls during init. */
! retval = request_irq(dev->irq, &speedo_interrupt, SA_SHIRQ,
dev->name, dev);
if (retval) {
MOD_DEC_USE_COUNT;
return retval;
--- 923,929 ----
sp->in_interrupt = 0;
/* .. we can safely take handler calls during init. */
! retval = request_irq(dev->irq, &speedo_interrupt, SA_SHIRQ |
SA_SAMPLE_RANDOM, dev->name, dev);
if (retval) {
MOD_DEC_USE_COUNT;
return retval;
[ENDS]
Alex Bligh - linux-kernel wrote:
> The machine in question is locked in a data center (can't be
> the only one) and thus sees none of the former two. IDE Entropy
> comes from executed IDE commands. The disk is physically largely
> inactive due to caching. But there's plenty of network traffic
> which should generate IRQs.
Use a hardware random number generator if you need a lot of entropy.
The i810 RNG driver and userspace tools at
http://sourceforge.net/project/gkernel/ provide an example for an
implementation, if your hardware is not i8xx.
> However, only 3 drivers in drivers/net actually set
> SA_SAMPLE_RANDOM when calling request_irq(). I believe
> all of them should.
No, because an attacker can potentially control input and make it
non-random.
Jeff
--
Jeff Garzik | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft | and shrieking like a cheerleader."
On Sun, Apr 08, 2001 at 11:46:21PM +0100, Alex Bligh - linux-kernel wrote:
> The following patch fixes eepro100.c - others can be
> patched similarly.
Problem is that it allows someone with sniffer access to your network to
make a pretty good estimate of your random pool. If you search the archives
there was a big discussion about it some months ago. Currently there is no
good solution, except for using add-on hardware that offers randomness
(that can be as simple as a spare sound card with some noise input)
-Andi
Alex Bligh - linux-kernel wrote:
>In debugging why my (unloaded) IMAP server takes many seconds
>to open folders, I discovered what looks like a problem
>in 2.4's feeding of entropy into /dev/random. When there
>is insufficient entropy in the random number generator,
>reading from /dev/random blocks for several seconds. /dev/random
>is used (correctly) for crytographic key verification.
Use /dev/urandom, or buy a hardware RNG.
>However, only 3 drivers in drivers/net actually set
>SA_SAMPLE_RANDOM when calling request_irq(). I believe
>all of them should. And indeed this fixed the problem for
>me using an eepro100().
This is unsafe. The time that packets arrive is not secret:
anyone who can run a sniffer on your network can potentially
recover this information. Thus, such timings are unsuitable
for introduction into the entropy pool.
(More precisely, there's no harm in adding them to the entropy
pool if they are added in a way so that the /dev/random pool
doesn't increment its estimate of how much entropy it has
collected. The real harm comes when you bump up the randomness
counter based on them, and if I understand your proposed change,
this is what it's doing.)
Jeff et al.,
>> However, only 3 drivers in drivers/net actually set
>> SA_SAMPLE_RANDOM when calling request_irq(). I believe
>> all of them should.
>
> No, because an attacker can potentially control input and make it
> non-random.
Point taken but:
1. In that case, if we follow your logic, no drivers (rather than 3
arbitrary ones) should set SA_SAMPLE_RANDOM
2. Given that otherwise in at least my application (and machine
without keyboard and mouse can't be too uncommon) there is *no*
entropy otherwise, which is rather easier for a hacker. At least
with entropy from a (albeit predictable) network, his attack
is going to shift the state of the seed (in an albeit predictable
manner), though he's going to have to make some accurate guesses
each time about the forwarding delay of the router in front of it,
and the stream of other packets hitting the server. I'd rather rely
on this, than rely on cron (which is effectively what is driving
any disk entropy every few minutes and is extremely predictable).
--
Alex Bligh
>> However, only 3 drivers in drivers/net actually set
>> SA_SAMPLE_RANDOM when calling request_irq(). I believe
>> all of them should.
> No, because an attacker can potentially control input and make it
> non-random.
AB> 2. Given that otherwise in at least my application (and machine
AB> without keyboard and mouse can't be too uncommon) there is *no*
AB> entropy otherwise, which is rather easier for a hacker. At least
Put a soundcard in your system and install audio-entropyd.
Works pretty nice.
On Mon, Apr 09, 2001 at 01:04:47PM +0200, Heusden, Folkert van wrote:
> >> However, only 3 drivers in drivers/net actually set
> >> SA_SAMPLE_RANDOM when calling request_irq(). I believe
> >> all of them should.
> > No, because an attacker can potentially control input and make it
> > non-random.
> AB> 2. Given that otherwise in at least my application (and machine
> AB> without keyboard and mouse can't be too uncommon) there is *no*
> AB> entropy otherwise, which is rather easier for a hacker. At least
>
> Put a soundcard in your system and install audio-entropyd.
> Works pretty nice.
Do you know where to find it? Freshmeat has a listing, but it's pointing
to mindrot.org and is 404 not found.
-- Ferret
> AB> 2. Given that otherwise in at least my application (and machine
> AB> without keyboard and mouse can't be too uncommon) there is *no*
> AB> entropy otherwise, which is rather easier for a hacker. At least
> Put a soundcard in your system and install audio-entropyd.
> Works pretty nice.
I> Do you know where to find it? Freshmeat has a listing, but it's
I> pointing to mindrot.org and is 404 not found.
I still had the tgz-file. You can download the tarball from:
http://www.vanheusden.com/mirrors/