* no entropy and no output at /dev/random (quick question)
@ 2004-11-27 2:59 Javier Villavicencio
2004-11-27 4:38 ` Javier Villavicencio
2004-11-27 19:22 ` Jan Engelhardt
0 siblings, 2 replies; 15+ messages in thread
From: Javier Villavicencio @ 2004-11-27 2:59 UTC (permalink / raw)
To: Linux Kernel
Hi, i've just suscribed from work to the list (now my boss will have to
buy a new server :+)
The quick question/problem follows:
I have a server that runs kernel 2.6.9, some web and monitoring
services, it's connected to two different networks with two different
network cards, and somehow a php developer discovered that /dev/random
wasn't giving any entropy to him (O_O) so i checked it out...
the (BUG??) follows:
(via ssh, i have no keyboard there)
# cat /dev/random (5 minutes, the server working, nothing)
ctrl+c
# cat /dev/urandom
<snip> (lots of randomness)
then I went to /proc/sys/kernel/random
# /proc/sys/kernel/random
# cat entropy_avail
0
# OMG!
-bash: OMG1: command not found
O_O. No entropy available. WTF??
Then i did a little search in the whole source directory of the kernel
(looking for entropy sources) and I've found that NONE OF MY (interrupts
generating) HARDWARE was (contributing??) helping with the entropy.
This is the (little) summary of the "working" stuff.
* 3Com Corporation 3c905B 100BaseTX (driver 3c59x.c doesn't give any
entropy).
* Intel Corp. 82557/8/9 [Ethernet Pro 100] (driver eepro100.c o_O)
* Mylex Corporation DAC960PRL (driver DAC960.c neither)
So and this is the /proc/interrupts output:
0: 2991777 15 IO-APIC-edge timer
2: 0 0 XT-PIC cascade
5: 434913 1 IO-APIC-level eth0
8: 2 0 IO-APIC-edge rtc
9: 383701 0 IO-APIC-level eth1
10: 101 0 IO-APIC-level sym53c8xx
11: 0 0 IO-APIC-level uhci_hcd
15: 14543 1 IO-APIC-level Mylex DAC960PG
As you may see my only sources of entropy where the timer, eth0, eth1
and the DAC960.
So I patched my 3 drivers (near request_irq, sending SA_SAMPLE_RANDOM |
SA_SHIRQ in the call).
Now I have entropy :+):
# cat /proc/sys/kernel/random/entropy_avail
4096
The quick question (at last), is this "right?" I mean, everything works
as before, no problems (so far) and the php developer is happy. It is
"risky" to put this in the DAC960 driver? (seems pretty much complicated
compared with others i've touched in my life)
Thanks for any advice.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: no entropy and no output at /dev/random (quick question)
2004-11-27 2:59 no entropy and no output at /dev/random (quick question) Javier Villavicencio
@ 2004-11-27 4:38 ` Javier Villavicencio
2004-11-27 19:20 ` David Wagner
2004-11-27 19:24 ` Jan Engelhardt
2004-11-27 19:22 ` Jan Engelhardt
1 sibling, 2 replies; 15+ messages in thread
From: Javier Villavicencio @ 2004-11-27 4:38 UTC (permalink / raw)
To: Linux Kernel
Javier Villavicencio wrote:
>
> # cat /dev/random (5 minutes, the server working, nothing)
> ctrl+c
> # cat /dev/urandom
> <snip> (lots of randomness)
Playing with my desktop machine (which is newer and completely different
from the servers) I've found that I run out of entropy -REALLY FAST-,
even this one is supposed to have those hardware random stuff generators.
Is this a normal behaviour?, or, I think i've readed this somewhere,
it's encouraged to use /dev/urandom instead of /dev/random?
Salu2.
--
Javier Villavicencio
Administrador/Consultor
Direccion Nacional de Migraciones
Ministerio del Interior
Republica Argentina
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: no entropy and no output at /dev/random (quick question)
2004-11-27 4:38 ` Javier Villavicencio
@ 2004-11-27 19:20 ` David Wagner
2004-11-28 6:29 ` Herbert Xu
2004-11-30 12:49 ` Horst von Brand
2004-11-27 19:24 ` Jan Engelhardt
1 sibling, 2 replies; 15+ messages in thread
From: David Wagner @ 2004-11-27 19:20 UTC (permalink / raw)
To: linux-kernel
Javier Villavicencio wrote:
>it's encouraged to use /dev/urandom instead of /dev/random?
Yes, for almost all purposes, applications should use /dev/urandom,
not /dev/random. (The names for these devices are unfortunate.)
Sadly, many applications fail to follow these rules, and consequently
/dev/random's entropy pool often ends up getting depleted much faster
than it has to be.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: no entropy and no output at /dev/random (quick question)
2004-11-27 2:59 no entropy and no output at /dev/random (quick question) Javier Villavicencio
2004-11-27 4:38 ` Javier Villavicencio
@ 2004-11-27 19:22 ` Jan Engelhardt
2004-11-27 19:42 ` Andreas Steinmetz
2004-11-29 22:51 ` Javier Villavicencio
1 sibling, 2 replies; 15+ messages in thread
From: Jan Engelhardt @ 2004-11-27 19:22 UTC (permalink / raw)
To: Javier Villavicencio; +Cc: Linux Kernel
>I have a server that runs kernel 2.6.9, some web and monitoring
>services, it's connected to two different networks with two different
>network cards, and somehow a php developer discovered that /dev/random
>wasn't giving any entropy to him (O_O) so i checked it out...
>[...]
>As you may see my only sources of entropy where the timer, eth0, eth1
>and the DAC960.
I doubt that timer and eth* are a non-predictable source. As such, they should
not contribute to the entropy. Better is the keyboard and/or mouse. SSH traffic
is network traffic, and if you send it to a network card, you can expect an
interrupt at <time>... prdictable.
Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, www.gwdg.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: no entropy and no output at /dev/random (quick question)
2004-11-27 4:38 ` Javier Villavicencio
2004-11-27 19:20 ` David Wagner
@ 2004-11-27 19:24 ` Jan Engelhardt
1 sibling, 0 replies; 15+ messages in thread
From: Jan Engelhardt @ 2004-11-27 19:24 UTC (permalink / raw)
To: Javier Villavicencio; +Cc: Linux Kernel
>Is this a normal behaviour?, or, I think i've readed this somewhere,
Yes, standard behavior. Programs using /dev/random even request you to hit a
few keys or move the mouse.
>it's encouraged to use /dev/urandom instead of /dev/random?
Yes, because 'random' might run out of entropy.
>
Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, www.gwdg.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: no entropy and no output at /dev/random (quick question)
2004-11-27 19:22 ` Jan Engelhardt
@ 2004-11-27 19:42 ` Andreas Steinmetz
2004-11-27 21:35 ` David Schwartz
2004-11-29 22:47 ` Javier Villavicencio
2004-11-29 22:51 ` Javier Villavicencio
1 sibling, 2 replies; 15+ messages in thread
From: Andreas Steinmetz @ 2004-11-27 19:42 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Javier Villavicencio, Linux Kernel
Jan Engelhardt wrote:
> I doubt that timer and eth* are a non-predictable source. As such, they should
> not contribute to the entropy. Better is the keyboard and/or mouse. SSH traffic
> is network traffic, and if you send it to a network card, you can expect an
> interrupt at <time>... prdictable.
Timer, ok. But network - only if you are in full control of the network
segment the system is attached to which may be the case for your private
network but usually you can't predict what network traffic is actually
going on.
--
Andreas Steinmetz SPAMmers use robotrap@domdv.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: no entropy and no output at /dev/random (quick question)
2004-11-27 19:42 ` Andreas Steinmetz
@ 2004-11-27 21:35 ` David Schwartz
2004-11-27 21:44 ` Jan Engelhardt
2004-11-29 22:47 ` Javier Villavicencio
1 sibling, 1 reply; 15+ messages in thread
From: David Schwartz @ 2004-11-27 21:35 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Javier Villavicencio, Linux Kernel
> Timer, ok. But network - only if you are in full control of the network
> segment the system is attached to which may be the case for your private
> network but usually you can't predict what network traffic is actually
> going on.
You would need a lot more than that to predict the TSC value when a packet
is received. All kinds of unpredictable elements get mixed in, such as the
offset between the network's timing source and the processor's as well as
the cache efficiency in getting the networking code running to the point
that it checks the TSC.
DS
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: no entropy and no output at /dev/random (quick question)
2004-11-27 21:35 ` David Schwartz
@ 2004-11-27 21:44 ` Jan Engelhardt
0 siblings, 0 replies; 15+ messages in thread
From: Jan Engelhardt @ 2004-11-27 21:44 UTC (permalink / raw)
Cc: Linux Kernel
>> Timer, ok. But network - only if you are in full control of the network
>> segment the system is attached to which may be the case for your private
>> network but usually you can't predict what network traffic is actually
>> going on.
>
> You would need a lot more than that to predict the TSC value when a packet
>is received. All kinds of unpredictable elements get mixed in, such as the
>offset between the network's timing source and the processor's as well as
>the cache efficiency in getting the networking code running to the point
>that it checks the TSC.
Sounds like I started a hell of a discussion (again) :)
Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, www.gwdg.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: no entropy and no output at /dev/random (quick question)
2004-11-27 19:20 ` David Wagner
@ 2004-11-28 6:29 ` Herbert Xu
2004-11-29 15:32 ` Theodore Ts'o
2004-11-30 12:49 ` Horst von Brand
1 sibling, 1 reply; 15+ messages in thread
From: Herbert Xu @ 2004-11-28 6:29 UTC (permalink / raw)
To: David Wagner; +Cc: linux-kernel
David Wagner <daw@taverner.cs.berkeley.edu> wrote:
>
> Yes, for almost all purposes, applications should use /dev/urandom,
> not /dev/random. (The names for these devices are unfortunate.)
> Sadly, many applications fail to follow these rules, and consequently
> /dev/random's entropy pool often ends up getting depleted much faster
> than it has to be.
I agree with your conclusion that applications should use urandom.
However, IIRC /dev/urandom depletes the entropy pool just as fast
as /dev/random...
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: no entropy and no output at /dev/random (quick question)
2004-11-28 6:29 ` Herbert Xu
@ 2004-11-29 15:32 ` Theodore Ts'o
0 siblings, 0 replies; 15+ messages in thread
From: Theodore Ts'o @ 2004-11-29 15:32 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Wagner, linux-kernel
On Sun, Nov 28, 2004 at 05:29:45PM +1100, Herbert Xu wrote:
> David Wagner <daw@taverner.cs.berkeley.edu> wrote:
> >
> > Yes, for almost all purposes, applications should use /dev/urandom,
> > not /dev/random. (The names for these devices are unfortunate.)
> > Sadly, many applications fail to follow these rules, and consequently
> > /dev/random's entropy pool often ends up getting depleted much faster
> > than it has to be.
>
> I agree with your conclusion that applications should use urandom.
> However, IIRC /dev/urandom depletes the entropy pool just as fast
> as /dev/random...
More specifically, most applications should use /dev/urandom to seed a
cryptographic random number generator which operates in userspace.
- Ted
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: no entropy and no output at /dev/random (quick question)
2004-11-27 19:42 ` Andreas Steinmetz
2004-11-27 21:35 ` David Schwartz
@ 2004-11-29 22:47 ` Javier Villavicencio
1 sibling, 0 replies; 15+ messages in thread
From: Javier Villavicencio @ 2004-11-29 22:47 UTC (permalink / raw)
To: Andreas Steinmetz; +Cc: Jan Engelhardt, Linux Kernel
Andreas Steinmetz wrote:
> Jan Engelhardt wrote:
>
>> I doubt that timer and eth* are a non-predictable source. As such,
>> they should
>> not contribute to the entropy. Better is the keyboard and/or mouse.
>> SSH traffic
>> is network traffic, and if you send it to a network card, you can
>> expect an
>> interrupt at <time>... prdictable.
>
>
> Timer, ok. But network - only if you are in full control of the network
> segment the system is attached to which may be the case for your private
> network but usually you can't predict what network traffic is actually
> going on.
I'm in control of "one" of the network segments, the other is connected
to the internet which is a bad source of entropy I know, so I've enabled
the SA_SAMPLE_RANDOM in the request_irq() call just for my local lan
nic, but the "other" source of good entropy should be the DAC(RAID)
controller, right?, I was just curious about why this driver didn't had
this flag enabled in its request_irq call.
--
Javier Villavicencio
Administrador/Consultor
Direccion Nacional de Migraciones
Ministerio del Interior
Republica Argentina
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: no entropy and no output at /dev/random (quick question)
2004-11-27 19:22 ` Jan Engelhardt
2004-11-27 19:42 ` Andreas Steinmetz
@ 2004-11-29 22:51 ` Javier Villavicencio
1 sibling, 0 replies; 15+ messages in thread
From: Javier Villavicencio @ 2004-11-29 22:51 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Linux Kernel
Jan Engelhardt wrote:
>>I have a server that runs kernel 2.6.9, some web and monitoring
>>services, it's connected to two different networks with two different
>>network cards, and somehow a php developer discovered that /dev/random
>>wasn't giving any entropy to him (O_O) so i checked it out...
>>[...]
>>As you may see my only sources of entropy where the timer, eth0, eth1
>>and the DAC960.
>
>
> I doubt that timer and eth* are a non-predictable source. As such, they should
> not contribute to the entropy. Better is the keyboard and/or mouse. SSH traffic
> is network traffic, and if you send it to a network card, you can expect an
> interrupt at <time>... prdictable.
>
>
> Jan Engelhardt
Hmm you got it wrong, I'm saying that my only "interrupt generating
hardware" was NOT contributing to the entropy. I mean, the timer (OF
COURSE NOT) and the NICs (same) but why don't the DAC960???
--
Javier Villavicencio
Administrador/Consultor
Direccion Nacional de Migraciones
Ministerio del Interior
Republica Argentina
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: no entropy and no output at /dev/random (quick question)
2004-11-27 19:20 ` David Wagner
2004-11-28 6:29 ` Herbert Xu
@ 2004-11-30 12:49 ` Horst von Brand
2004-11-30 16:48 ` Javier Villavicencio
1 sibling, 1 reply; 15+ messages in thread
From: Horst von Brand @ 2004-11-30 12:49 UTC (permalink / raw)
To: David Wagner; +Cc: linux-kernel
daw@taverner.cs.berkeley.edu (David Wagner) said:
> Javier Villavicencio wrote:
> >it's encouraged to use /dev/urandom instead of /dev/random?
> Yes, for almost all purposes, applications should use /dev/urandom,
> not /dev/random. (The names for these devices are unfortunate.)
To seed a random number generator, never directly.
> Sadly, many applications fail to follow these rules, and consequently
> /dev/random's entropy pool often ends up getting depleted much faster
> than it has to be.
Reading /dev/urandom depletes exactly the same pool, it just doesn't block
when the pool is empty. As said pool has other uses, indiscriminate reading
of either can DoS other parts of the system.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: no entropy and no output at /dev/random (quick question)
2004-11-30 12:49 ` Horst von Brand
@ 2004-11-30 16:48 ` Javier Villavicencio
2005-01-07 19:17 ` Denis Vlasenko
0 siblings, 1 reply; 15+ messages in thread
From: Javier Villavicencio @ 2004-11-30 16:48 UTC (permalink / raw)
To: Horst von Brand; +Cc: David Wagner, linux-kernel
Horst von Brand wrote:
> daw@taverner.cs.berkeley.edu (David Wagner) said:
>
>>Javier Villavicencio wrote:
>>
>>>it's encouraged to use /dev/urandom instead of /dev/random?
>
>
>>Yes, for almost all purposes, applications should use /dev/urandom,
>>not /dev/random. (The names for these devices are unfortunate.)
>
>
> To seed a random number generator, never directly.
>
>
>>Sadly, many applications fail to follow these rules, and consequently
>>/dev/random's entropy pool often ends up getting depleted much faster
>>than it has to be.
>
>
> Reading /dev/urandom depletes exactly the same pool, it just doesn't block
> when the pool is empty. As said pool has other uses, indiscriminate reading
> of either can DoS other parts of the system.
But why if /dev/random depletes and you don't have any source of entropy
? As you may have seen in my setup I had no mouse/keyboard attached to
that server, and the only "things" capable of generate entropy where the
two nics and the DAC960.
So I've enabled entropy only for the local nic and the DAC960 (at least
"I think", for the dac :+) and now I'm plenty of entropy, but for a
setup like this, the server may have been running without entropy at all
for weeks (I've forgot to check the uptime :+P).
About this, think about php generating session_id()s without entropy
(o_O), and stuff like that....
Salu2.
Javier Villavicencio.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: no entropy and no output at /dev/random (quick question)
2004-11-30 16:48 ` Javier Villavicencio
@ 2005-01-07 19:17 ` Denis Vlasenko
0 siblings, 0 replies; 15+ messages in thread
From: Denis Vlasenko @ 2005-01-07 19:17 UTC (permalink / raw)
To: Javier Villavicencio, Horst von Brand; +Cc: David Wagner, linux-kernel
On Tuesday 30 November 2004 18:48, Javier Villavicencio wrote:
> > Reading /dev/urandom depletes exactly the same pool, it just doesn't block
> > when the pool is empty. As said pool has other uses, indiscriminate reading
> > of either can DoS other parts of the system.
>
> But why if /dev/random depletes and you don't have any source of entropy
> ? As you may have seen in my setup I had no mouse/keyboard attached to
> that server, and the only "things" capable of generate entropy where the
> two nics and the DAC960.
> So I've enabled entropy only for the local nic and the DAC960 (at least
> "I think", for the dac :+) and now I'm plenty of entropy, but for a
> setup like this, the server may have been running without entropy at all
> for weeks (I've forgot to check the uptime :+P).
> About this, think about php generating session_id()s without entropy
> (o_O), and stuff like that....
BTW why your php developer can't use /dev/urandom?
--
vda
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2005-01-07 19:23 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-11-27 2:59 no entropy and no output at /dev/random (quick question) Javier Villavicencio
2004-11-27 4:38 ` Javier Villavicencio
2004-11-27 19:20 ` David Wagner
2004-11-28 6:29 ` Herbert Xu
2004-11-29 15:32 ` Theodore Ts'o
2004-11-30 12:49 ` Horst von Brand
2004-11-30 16:48 ` Javier Villavicencio
2005-01-07 19:17 ` Denis Vlasenko
2004-11-27 19:24 ` Jan Engelhardt
2004-11-27 19:22 ` Jan Engelhardt
2004-11-27 19:42 ` Andreas Steinmetz
2004-11-27 21:35 ` David Schwartz
2004-11-27 21:44 ` Jan Engelhardt
2004-11-29 22:47 ` Javier Villavicencio
2004-11-29 22:51 ` Javier Villavicencio
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).