randomness - compaq smart array driver

randomness - compaq smart array driver

[Proescholdt, timo]

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

Re: randomness - compaq smart array driver

[Tim Schmielau]

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://www.*.kernel.org/pub/linux/kernel/people/rml/netdev-random/
or
  http://www.tech9.net/rml/linux/

Tim

Re: randomness - compaq smart array driver

[Ken Brownfield]

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.
brownfld@irridia.com

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://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 majordomo@vger.kernel.org
| More majordomo info at  http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at  http://www.tux.org/lkml/

Re: randomness - compaq smart array driver

[Sean Hunter]

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

Re: randomness - compaq smart array driver

[Chris Friesen]

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: cfriesen@nortelnetworks.com

RE: randomness - compaq smart array driver

[Stephen Cameron]

timo (Timo.Proescholdt@brk-muenchen.de) 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);