[lkml]   [2001]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH][RFC] Allow net devices to contribute to /dev/random
Updated versions of my netdev-random patch are out.  The patchset is two
piece: one containing the core code and two containing the updated



ChangeLog and more information:

Quick summary: This patch enables a new configure option that allows
users to allow whether network devices can contribute to /dev/random.
Normally block devices and the keyboard contribute, although very few
network devices do. This patch makes a user-configurable policy out of
the issue: either allow them all or disallow them all. Some users, such
as those on a headless or diskless system, have little or no entropy.
This patch will give them that entropy. Summarizing the discussion on
the issue, as long as SHA-1 is secure or your network traffic is secure,
this is safe. For those who don't want the option, leave the setting
disabled and no NIC will contribute.

How it works: defines a new flag for each architecture,
SA_SAMPLE_NET_RANDOM which defines to 0 or SA_SAMPLE_RANDOM depending on
the value of the configure statement.

All architectures and all network devices are supported. The lastest
patch fixes a few typos and the like.

[You can ignore further if you just wanted the newest patch]

Now, why this I ask for comments. An alternative approach to this is to
not have a configure setting but instead have a /proc interface. When
disabled, interrupts will not contribute, and when enabled, they will.

The code is something like this:

(like with the normal patch).

let random_netdev_contribute be 0 or 1 set from the /proc interface.

in setup_irq and handle_IRQ_event() we change:

if (status & SA_SAMPLE_RANDOM)


if ((status & SA_SAMPLE_RANDOM) ||
((status & SA_SAMPLE_NET_RANDOM) && random_netdev_contrib))

That's about it. Most of the code I have is for the proc interface.

One problem, and one concern.

The problem: setup_irq is called on device setup. this means that
in-kernel drivers and modules loaded before the /proc interface is set
will have the wrong value registered in setup_irq. I am not too sure
what this entails

Ie, if random_netdev_contrib=0 when we call setup_irq, we won't call
rand_initialize_irq() but then if random_netdev_contrib is set to 1, we
will all of a sudden start calling add_interrupt_randomness()! You can
see the reverse of this, too, where we will initialize it but not call

Changing the proc entry on the fly and/or loading/unloading modules just
adds to this mess.

I just don't think this will work cleanly.

Finally, my concern is that the if statement is not the cleanest. We
have to check for the normal SA_SAMPLE_RANDOM flag, and then we need to
check for the other possibility of the NET version of the flag. If it
exists, we need to see if random_netdev_contrib is set. Not very
clean. A cleaner design, anyone?

I am happy to just leave the patch as is, and right now I am thinking I
will do just that.

Robert M. Love
rml at
rml at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.119 / U:6.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site