Hi Linux community,
I have a question concerning /dev/random on proliant servers with
smart array controllers.
A month ago i tried to install freeswan on a proliant dl360 box,
running redhat 6.2 on a smart array controller.
There are no disks hanging at the scsi controller only the
two disks at the smart array controller channel. Kernel is 2.4.14 .
I noticed that the installation fails due to missing randomness.
I can confirm that as cat /dev/random does not provide any output.
Looking and asking arround i found out that the smart array
controller driver has a bug (?) so that it does not provide
any information to the kernel random functions.
Because i am working on the machine over a ssh connection
there is no mouse / keyboard input, so randomness
depends on disk aktivity only. As the only disks on the
system are connected to the smart array controller
no random data can be created.
I heard that there is a patch for 2.2.x kernels, wich deals with this
topic , but i cannot find this patch anywere .
Is there a similar patch for 2.4.x kernels?
Will this problem be solved in the next future?
Can anybody tell me if this problem is known, are there
any workarrounds / solutions ?
many thanks
Timo Proescholdt
On Mon, 11 Feb 2002, Proescholdt, timo wrote:
> I noticed that the installation fails due to missing randomness.
> I can confirm that as cat /dev/random does not provide any output.
[...]
> I heard that there is a patch for 2.2.x kernels, wich deals with this
> topic , but i cannot find this patch anywere .
> Is there a similar patch for 2.4.x kernels?
Robert Love did a patch to let network devices contribute to the random
pool. Look at
ftp://http://www.*.kernel.org/pub/linux/kernel/people/rml/netdev-random/
or
http://www.tech9.net/rml/linux/
Tim
timo ([email protected]) wrote:
> I have a question concerning /dev/random on proliant servers with
> smart array controllers.
> A month ago i tried to install freeswan on a proliant dl360 box,
> running redhat 6.2 on a smart array controller.
> There are no disks hanging at the scsi controller only the
> two disks at the smart array controller channel. Kernel is 2.4.14 .
As it happens, we just sent this patch to Jens on Friday,
I tried it and meant it for 2.5.4-pre2 and -pre3. I
think it ought to be good for 2.4.x as well though.
-- steve
diff -urN lx254p2-c3/drivers/block/cciss.c lx254p2-c4/drivers/block/cciss.c
--- lx254p2-c3/drivers/block/cciss.c Thu Feb 7 14:35:31 2002
+++ lx254p2-c4/drivers/block/cciss.c Thu Feb 7 14:50:43 2002
@@ -2467,7 +2467,8 @@
/* make sure the board interrupts are off */
hba[i]->access.set_intr_mask(hba[i], CCISS_INTR_OFF);
if( request_irq(hba[i]->intr, do_cciss_intr,
- SA_INTERRUPT|SA_SHIRQ, hba[i]->devname, hba[i]))
+ SA_INTERRUPT | SA_SHIRQ | SA_SAMPLE_RANDOM,
+ hba[i]->devname, hba[i]))
{
printk(KERN_ERR "ciss: Unable to get irq %d for %s\n",
hba[i]->intr, hba[i]->devname);
Yes, I've been using the netdev patches for months. Aside from the
unrelated entropy exhaustion bug, his patches are stable (and optional)
and help on diskless or low-I/O machines. 2.4 or 2.5 anyone? :)
--
Ken.
[email protected]
On Mon, Feb 11, 2002 at 05:58:37PM +0100, Tim Schmielau wrote:
| On Mon, 11 Feb 2002, Proescholdt, timo wrote:
|
| > I noticed that the installation fails due to missing randomness.
| > I can confirm that as cat /dev/random does not provide any output.
| [...]
| > I heard that there is a patch for 2.2.x kernels, wich deals with this
| > topic , but i cannot find this patch anywere .
| > Is there a similar patch for 2.4.x kernels?
|
| Robert Love did a patch to let network devices contribute to the random
| pool. Look at
| ftp://http://www.*.kernel.org/pub/linux/kernel/people/rml/netdev-random/
| or
| http://www.tech9.net/rml/linux/
|
| Tim
|
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to [email protected]
| More majordomo info at http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at http://www.tux.org/lkml/
On Wed, Feb 13, 2002 at 07:14:45AM -0600, Ken Brownfield wrote:
> Yes, I've been using the netdev patches for months. Aside from the
> unrelated entropy exhaustion bug, his patches are stable (and optional)
> and help on diskless or low-I/O machines. 2.4 or 2.5 anyone? :)
Randomness from network packet timings can be gathered entirely in userspace by
using a packet socket. I am busy writing an "additional entropy daemon" to
gather entropy from this and other sources[1], clean it up, test its fitness,
estimate its information content, and feed it into the random pool. This job
is (IMO) better done in userspace because there we can run fitness tests on the
stream more easily because we have floating point etc.
I personally don't think that network packet timings should be added to the
entropy pool by the kernel because they could be controlled to a lesser or
greater extent by an attacker. I'm hoping that the fitness tests in my
userspace thingy would detect this.
Sean
[1] Including clock jitter and soundcard noise (I got the idea
from Schneier 1996).
Sean Hunter wrote:
> Randomness from network packet timings can be gathered entirely in userspace by
> using a packet socket. I am busy writing an "additional entropy daemon" to
> gather entropy from this and other sources[1], clean it up, test its fitness,
> estimate its information content, and feed it into the random pool. This job
> is (IMO) better done in userspace because there we can run fitness tests on the
> stream more easily because we have floating point etc.
However, if you're doing that, then you incur the cost of copying every incoming
packet and sending it up to userspace. For a busy server, this could be
unacceptable.
Also, how are you timing the incoming packets? In kernel space we can get
accuracy of a few tens of nanoseconds for timing the interrupts--how do you
approach this in userspace when your userspace process can be scheduled out?
Even if we timestamp the packets with microsecond accuracy, we are still a few
orders of magnitude short of the accuracy attainable in the kernel, with
correspondingly less entropy that can be extracted.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]