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.
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
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.
>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, http://www.gwdg.de
>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, http://www.gwdg.de
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 [email protected]
> 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
>> 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, http://www.gwdg.de
David Wagner <[email protected]> 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~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Sun, Nov 28, 2004 at 05:29:45PM +1100, Herbert Xu wrote:
> David Wagner <[email protected]> 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
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
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