Problem with random.c and PPC
Hello !!!
I am trying to use a program (ipsec newhostkey) that uses the random device provided by the linux-kernel. In a x86 machine the program works fine but when I tried to run the program in a PPC machine it doesn't work.
Looking carefully I have discovered that the problem is in the driver random.c. When the program tries to read any amount of data it locks and never returns. It happens because the variable "random_state->entropy_count" is always zero, that is, any random number is generated at all !!!??.
Does anyone know anything about this problem ? Any sort of help is very welcomed.
Thanks
Henrique Gobbi
Quoted 6 lines · henrique
Hello !!!
I am trying to use a program (ipsec newhostkey) that uses the random device provided by the linux-kernel. In a x86 machine the program works fine but when I tried to run the program in a PPC machine it doesn't work.
Quoted 7 lines
Looking carefully I have discovered that the problem is in the driver
random.c. When the program tries to read any amount of data it locks and never returns. It happens because the variable "random_state->entropy_count" is always zero, that is, any random number is generated at all !!!??.Does anyone know anything about this problem ? Any sort of help is very welcomed.
Maybe the PPC keyboard/mouse drivers do not add randomness? You should also get randomness from disk I/O. If your PPC system is diskless, mouseless, and keyboardless, there is also a patch for 2.4 which allows you to get randomness from network card interrupts, which is good enough for all but the most incredibly paranoid people.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
Quoted 12 lines · Andreas Dilger
Quoted 11 lines · henrique
Hello !!!
I am trying to use a program (ipsec newhostkey) that uses the random device provided by the linux-kernel. In a x86 machine the program works fine but when I tried to run the program in a PPC machine it doesn't work.
Looking carefully I have discovered that the problem is in the driver
random.c. When the program tries to read any amount of data it locks and never returns. It happens because the variable "random_state->entropy_count" is always zero, that is, any random number is generated at all !!!??.
Quoted 4 lines
Quoted 2 lines
Does anyone know anything about this problem ? Any sort of help is very welcomed.
Maybe the PPC keyboard/mouse drivers do not add randomness?
Well, how is this set for the i386 ones? I grepped around and I didn't really see anything, so I'm sort-of confused.
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Quoted 5 lines · Tom Rini
Quoted 1 line · Andreas Dilger
Maybe the PPC keyboard/mouse drivers do not add randomness?
Well, how is this set for the i386 ones? I grepped around and I didn't really see anything, so I'm sort-of confused.
I think it is something like "add_mouse_entropy" and "add_keyboard_entropy" or similar. If you look at the random.c sources you can find the actual function names and work backwards from there.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
Quoted 10 lines · Andreas Dilger
Quoted 5 lines · Tom Rini
Quoted 1 line · Andreas Dilger
Maybe the PPC keyboard/mouse drivers do not add randomness?
Well, how is this set for the i386 ones? I grepped around and I didn't really see anything, so I'm sort-of confused.
I think it is something like "
add_mouse_entropy" and "add_keyboard_entropy" or similar. If you look at therandom.csources you can find the actual function names and work backwards from there.
Ah, thanks. In that case, no. It doesn't look like the input-layer USB keyboards contribute to entropy (but mice do), and I don't think the ADB ones do. I'll take a crack at adding this to keyboards monday maybe.
Signature · 2 lines
Tom Rini (TR1265) http://gate.crashing.org/~trini/
Followup to: <[email protected]> By author: Tom Rini <[email protected]> In newsgroup: linux.dev.kernel
Quoted 5 lines
Ah, thanks. In that case, no. It doesn't look like the input-layer USB keyboards contribute to entropy (but mice do), and I don't think the ADB ones do. I'll take a crack at adding this to keyboards monday maybe.
Be careful... USB devices are *always* going to speak at the same place in the USB cycle... I believe that is 1 ms. Thus, submillisecond resolution is *not* random.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Quoted 4 lines · H. Peter Anvin
Followup to: <[email protected]> By author: Tom Rini <[email protected]> In newsgroup: linux.dev.kernelQuoted 1 line
Quoted 8 lines
Quoted 4 lines
Ah, thanks. In that case, no. It doesn't look like the input-layer USB keyboards contribute to entropy (but mice do), and I don't think the ADB ones do. I'll take a crack at adding this to keyboards monday maybe.
Be careful... USB devices are *always* going to speak at the same place in the USB cycle... I believe that is 1 ms. Thus, submillisecond resolution is *not* random.
Currently not a problem for anyone except X86, as they'll only use HZ resolution. But the same problem exists on regular mice and keyboards, which are typically scanned for events at a fixed rate.
This is just the tip of the iceberg for problems with entropy accounting. I've got some free time today, I'll try to clean up my patches for this.
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Quoted 8 lines · Tom Rini
Quoted 7 lines · Andreas Dilger
Quoted 5 lines · Tom Rini
Quoted 1 line · Andreas Dilger
Maybe the PPC keyboard/mouse drivers do not add randomness?
Well, how is this set for the i386 ones? I grepped around and I didn't really see anything, so I'm sort-of confused.
Quoted 7 lines
Quoted 3 lines
I think it is something like "
add_mouse_entropy" and "add_keyboard_entropy" or similar. If you look at therandom.csources you can find the actual function names and work backwards from there.Ah, thanks. In that case, no. It doesn't look like the input-layer USB keyboards contribute to entropy (but mice do), and I don't think the ADB ones do. I'll take a crack at adding this to keyboards monday maybe.
Tom, I'm working on a set of patches that completely change this interface because there are a bunch of problems with the current entropy accounting.
What PPC and other arches really need in this area is a higher resolution timing source. The jiffies-based timing is rather limiting, especially after the entropy accounting stops overestimating things by orders of magnitude. Does the PPC port have a convenient way to access the TBR or something similar?
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 11 lines · Tom Rini
Quoted 5 lines · Oliver Xymoron
What PPC and other arches really need in this area is a higher resolution timing source. The jiffies-based timing is rather limiting, especially after the entropy accounting stops overestimating things by orders of magnitude. Does the PPC port have a convenient way to access the TBR or something similar?
Not knowing i386 well, what's the TBR? But yes, on at least some of the cores I know there are time registers. I'm not sure if it's an optional feature for PPC or not tho.
I was actually referring to the PPC's time base register, which is about the closest equivalent to the x86's TSC. I'm pretty sure it's a non-optional architecture feature (but I don't have my books handy), and I believe this usually gets wired to the clock driving the memory bus (typically 133MHz), but I've only worked with embedded PPC so I have no idea how it's set up in commodity hardware.
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."