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:
define SA_SAMPLE_NET_RANDOM to be our new SA_SAMPLE_RANDOM for NICs
(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 ufl.edu rml at tech9.net
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 30 2001 - 21:00:38 EST