no entropy and no output at /dev/random (quick question)

no entropy and no output at /dev/random (quick question)

[Javier Villavicencio]

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.

Re: no entropy and no output at /dev/random (quick question)

[Javier Villavicencio]

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

Re: no entropy and no output at /dev/random (quick question)

[David Wagner]

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.

Re: no entropy and no output at /dev/random (quick question)

[Herbert Xu]

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

Re: no entropy and no output at /dev/random (quick question)

[Theodore Ts'o]

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

Re: no entropy and no output at /dev/random (quick question)

[Horst von Brand]

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

Re: no entropy and no output at /dev/random (quick question)

[Javier Villavicencio]

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.

Re: no entropy and no output at /dev/random (quick question)

[Denis Vlasenko]

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

Re: no entropy and no output at /dev/random (quick question)

[Jan Engelhardt]

>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

Re: no entropy and no output at /dev/random (quick question)

[Jan Engelhardt]

>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

Re: no entropy and no output at /dev/random (quick question)

[Andreas Steinmetz]

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

RE: no entropy and no output at /dev/random (quick question)

[David Schwartz]

> 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

RE: no entropy and no output at /dev/random (quick question)

[Jan Engelhardt]

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

Re: no entropy and no output at /dev/random (quick question)

[Javier Villavicencio]

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

Re: no entropy and no output at /dev/random (quick question)

[Javier Villavicencio]

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