Optionally let Net Devices feed Entropy

(patches will be attached in subsequent emails. there is a set for 2.4.9-pre4 and another for 2.4.8-ac5. Patch #1 includes the core code changes, configure changes, etc. Patch #2 includes some updated network drivers).

Its a long standing debate whether to allow network drivers to contribute to the kernel entropy pool. This e-mail is not to convince anyone of anything, but give users a choice.

Right now, a very small number of network devices add to /dev/random. The majority of them don't, presumably because of the fear of an external attacker manipulating the kernel entropy pool.

The following patches allow the user to configure at compile-time whether or not network devices should be allowed to feed the pool. For those of us who don't fear external attackers, this is a nice addition of entropy. It is also useful for those who are on a headless system and need some more sources of entropy.

A new configure statement is available in Network Devices. Enabling it enables CONFIG_NET_RANDOM which sets a new request_irq flag, SA_SAMPLE_RANDOM_NET. If enabled, that flag is defined as SA_SAMPLE_RANDOM. If disabled, the flag is defined as 0. Thus there is no additional code after compile.

The idea, then, should be to add SA_SAMPLE_RANDOM_NET to each network devices request_irq call.

Patch #2 does this for some devices: 3c501, 3c505, 3c509, 3c523, 3c59x, 8139too, cs89x0, eepro, eepro100, eexpress, ibmlana, ne2k-pci, pcnet_cs, xircom_tulic_cb, sk_mca, smc9194, tulic_core, and wavelan. All of the devices which already contribute entropy have been updated.

Robert M. Love
rml at ufl.edu
rml at tech9.net

against 2.4.9-pre4, patch #1 of 2 (required: adds the new define for all architectures, configure support, etc.) see previous email.

diff -urN linux-2.4.9-pre4/Documentation/Configure.help linux/Documentation/Configure.help
@@ -7728,6 +7728,19 @@
 
   If you don't know what to use this for, you don't need it.
 
+Allow Net Devices to contribute to /dev/random
+CONFIG_NET_RANDOM
+  If you say Y here, network device interrupts will contribute to the
+  kernel entropy pool at /dev/random. Normally, block devices and
+  some other devices (keyboard, mouse) add to the pool. Some people,
+  however, feel that network devices should not contribute to /dev/random
+  because an external attacker could manipulate incoming packets in a
+  manner to force the pool into a determinable state. Note this is
+  completely theoretical.
+
+  If you don't mind the risk or are using a headless system and are in
+  need of more entropy, say Y.
+
 Ethertap network tap (OBSOLETE)
 CONFIG_ETHERTAP
   If you say Y here (and have said Y to "Kernel/User network link

diff -urN linux-2.4.9-pre4/drivers/net/Config.in linux/drivers/net/Config.in
@@ -9,6 +9,7 @@
 tristate 'Bonding driver support' CONFIG_BONDING
 tristate 'EQL (serial line load balancing) support' CONFIG_EQUALIZER
 tristate 'Universal TUN/TAP device driver support' CONFIG_TUN
+bool 'Allow Net Devices to contribute to /dev/random' CONFIG_NET_RANDOM
 if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
    if [ "$CONFIG_NETLINK" = "y" ]; then
       tristate 'Ethertap network tap (OBSOLETE)' CONFIG_ETHERTAP

diff -urN linux-2.4.9-pre4/include/asm-alpha/signal.h linux/include/asm-alpha/signal.h
@@ -121,8 +121,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x40000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          1	/* for blocking signals */
 #define SIG_UNBLOCK        2	/* for unblocking signals */
 #define SIG_SETMASK        3	/* for setting the signal mask */

diff -urN linux-2.4.9-pre4/include/asm-arm/signal.h linux/include/asm-arm/signal.h
@@ -124,8 +124,20 @@
 #define SA_SAMPLE_RANDOM	0x10000000
 #define SA_IRQNOMASK		0x08000000
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.9-pre4/include/asm-cris/signal.h linux/include/asm-cris/signal.h
@@ -120,8 +120,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.9-pre4/include/asm-i386/signal.h linux/include/asm-i386/signal.h
@@ -119,8 +119,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.9-pre4/include/asm-ia64/signal.h linux/include/asm-ia64/signal.h
@@ -106,6 +106,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK          0	/* for blocking signals */

diff -urN linux-2.4.9-pre4/include/asm-m68k/signal.h linux/include/asm-m68k/signal.h
@@ -116,8 +116,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.9-pre4/include/asm-mips/signal.h linux/include/asm-mips/signal.h
@@ -111,6 +111,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x02000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK	1	/* for blocking signals */

diff -urN linux-2.4.9-pre4/include/asm-mips64/signal.h linux/include/asm-mips64/signal.h
@@ -112,6 +112,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x02000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK	1	/* for blocking signals */

diff -urN linux-2.4.9-pre4/include/asm-parisc/signal.h linux/include/asm-parisc/signal.h
@@ -100,6 +100,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK          0	/* for blocking signals */

diff -urN linux-2.4.9-pre4/include/asm-ppc/signal.h linux/include/asm-ppc/signal.h
@@ -114,8 +114,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.9-pre4/include/asm-s390/signal.h linux/include/asm-s390/signal.h
@@ -127,8 +127,20 @@
 #define SA_PROBE                SA_ONESHOT
 #define SA_SAMPLE_RANDOM        SA_RESTART
 #define SA_SHIRQ                0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0    /* for blocking signals */
 #define SIG_UNBLOCK        1    /* for unblocking signals */
 #define SIG_SETMASK        2    /* for setting the signal mask */

diff -urN linux-2.4.9-pre4/include/asm-s390x/signal.h linux/include/asm-s390x/signal.h
@@ -127,8 +127,20 @@
 #define SA_PROBE                SA_ONESHOT
 #define SA_SAMPLE_RANDOM        SA_RESTART
 #define SA_SHIRQ                0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0    /* for blocking signals */
 #define SIG_UNBLOCK        1    /* for unblocking signals */
 #define SIG_SETMASK        2    /* for setting the signal mask */

diff -urN linux-2.4.9-pre4/include/asm-sh/signal.h linux/include/asm-sh/signal.h
@@ -107,8 +107,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.9-pre4/include/asm-sparc/signal.h linux/include/asm-sparc/signal.h
@@ -176,8 +176,20 @@
 #define SA_PROBE SA_ONESHOT
 #define SA_SAMPLE_RANDOM SA_RESTART
 #define SA_STATIC_ALLOC		0x80
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 /* Type of a signal handler.  */
 #ifdef __KERNEL__
 typedef void (*__sighandler_t)(int, int, struct sigcontext *, char *);

diff -urN linux-2.4.9-pre4/include/asm-sparc64/signal.h linux/include/asm-sparc64/signal.h
@@ -192,8 +192,20 @@
 #define SA_PROBE SA_ONESHOT
 #define SA_SAMPLE_RANDOM SA_RESTART
 #define SA_STATIC_ALLOC		0x80
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 /* Type of a signal handler.  */
 #ifdef __KERNEL__
 typedef void (*__sighandler_t)(int, struct sigcontext *);

Robert M. Love
rml at ufl.edu
rml at tech9.net

against 2.4.9-pre4. patch 2 of 2 (updates some drivers to use new optional random support). see previous email.

diff -urN linux-2.4.9-pre4/drivers/net/3c501.c linux/drivers/net/3c501.c
@@ -410,7 +410,8 @@
 	if (el_debug > 2)
 		printk("%s: Doing el_open()...", dev->name);
 
-	if ((retval = request_irq(dev->irq, &el_interrupt, 0, dev->name, dev)))
+	if ((retval = request_irq(dev->irq, &el_interrupt,
+				SA_SAMPLE_NET_RANDOM, dev->name, dev)))
 		return retval;
 
 	spin_lock_irqsave(&lp->lock, flags);

diff -urN linux-2.4.9-pre4/drivers/net/3c505.c linux/drivers/net/3c505.c
@@ -897,7 +897,8 @@
 	/*
 	 * install our interrupt service routine
 	 */
-	if ((retval = request_irq(dev->irq, &elp_interrupt, 0, dev->name, dev))) {
+	if ((retval = request_irq(dev->irq, &elp_interrupt,
+					SA_SAMPLE_NET_RANDOM, dev->name, dev))) {
 		printk(KERN_ERR "%s: could not allocate IRQ%d\n", dev->name, dev->irq);
 		return retval;
 	}

diff -urN linux-2.4.9-pre4/drivers/net/3c509.c linux/drivers/net/3c509.c
@@ -560,7 +560,8 @@
 	outw(RxReset, ioaddr + EL3_CMD);
 	outw(SetStatusEnb | 0x00, ioaddr + EL3_CMD);
 
-	i = request_irq(dev->irq, &el3_interrupt, 0, dev->name, dev);
+	i = request_irq(dev->irq, &el3_interrupt,
+			SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (i) return i;
 
 	EL3WINDOW(0);

diff -urN linux-2.4.9-pre4/drivers/net/3c523.c linux/drivers/net/3c523.c
@@ -280,7 +280,7 @@
 
 	elmc_id_attn586();	/* disable interrupts */
 
-	ret = request_irq(dev->irq, &elmc_interrupt, SA_SHIRQ | SA_SAMPLE_RANDOM,
+	ret = request_irq(dev->irq, &elmc_interrupt, SA_SHIRQ | SA_SAMPLE_NET_RANDOM,
 			  dev->name, dev);
 	if (ret) {
 		printk(KERN_ERR "%s: couldn't get irq %d\n", dev->name, dev->irq);

diff -urN linux-2.4.9-pre4/drivers/net/3c59x.c linux/drivers/net/3c59x.c
@@ -1581,7 +1581,7 @@
 
 	/* Use the now-standard shared IRQ implementation. */
 	if ((retval = request_irq(dev->irq, vp->full_bus_master_rx ?
-				&boomerang_interrupt : &vortex_interrupt, SA_SHIRQ, dev->name, dev))) {
+				&boomerang_interrupt : &vortex_interrupt, SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev))) {
 		printk(KERN_ERR "%s: Could not reserve IRQ %d\n", dev->name, dev->irq);
 		goto out;
 	}

diff -urN linux-2.4.9-pre4/drivers/net/8139too.c linux/drivers/net/8139too.c
@@ -1289,7 +1289,8 @@
 
 	DPRINTK ("ENTER\n");
 
-	retval = request_irq (dev->irq, rtl8139_interrupt, SA_SHIRQ, dev->name, dev);
+	retval = request_irq (dev->irq, rtl8139_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (retval) {
 		DPRINTK ("EXIT, returning %d\n", retval);
 		return retval;

diff -urN linux-2.4.9-pre4/drivers/net/cs89x0.c linux/drivers/net/cs89x0.c
@@ -1057,7 +1057,7 @@
 
 		for (i = 2; i < CS8920_NO_INTS; i++) {
 			if ((1 << dev->irq) & lp->irq_map) {
-				if (request_irq(i, net_interrupt, 0, dev->name, dev) == 0) {
+				if (request_irq(i, net_interrupt, SA_SAMPLE_NET_RANDOM, dev->name, dev) == 0) {
 					dev->irq = i;
 					write_irq(dev, lp->chip_type, i);
 					/* writereg(dev, PP_BufCFG, GENERATE_SW_INTERRUPT); */

diff -urN linux-2.4.9-pre4/drivers/net/eepro.c linux/drivers/net/eepro.c
@@ -944,7 +944,8 @@
 		return -EAGAIN;
 	}
 		
-	if (request_irq(dev->irq , &eepro_interrupt, 0, dev->name, dev)) {
+	if (request_irq(dev->irq , &eepro_interrupt, SA_SAMPLE_NET_RANDOM,
+				dev->name, dev)) {
 		printk("%s: unable to get IRQ %d.\n", dev->name, dev->irq);
 		return -EAGAIN;
 	}

diff -urN linux-2.4.9-pre4/drivers/net/eepro100.c linux/drivers/net/eepro100.c
@@ -932,7 +932,8 @@
 	sp->in_interrupt = 0;
 
 	/* .. we can safely take handler calls during init. */
-	retval = request_irq(dev->irq, &speedo_interrupt, SA_SHIRQ, dev->name, dev);
+	retval = request_irq(dev->irq, &speedo_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (retval) {
 		MOD_DEC_USE_COUNT;
 		return retval;

diff -urN linux-2.4.9-pre4/drivers/net/eexpress.c linux/drivers/net/eexpress.c
@@ -433,7 +433,8 @@
 	if (!dev->irq || !irqrmap[dev->irq])
 		return -ENXIO;
 
-	ret = request_irq(dev->irq,&eexp_irq,0,dev->name,dev);
+	ret = request_irq(dev->irq,&eexp_irq,SA_SAMPLE_NET_RANDOM,
+			dev->name,dev);
 	if (ret) return ret;
 
 	request_region(ioaddr, EEXP_IO_EXTENT, "EtherExpress");

diff -urN linux-2.4.9-pre4/drivers/net/ibmlana.c linux/drivers/net/ibmlana.c
@@ -856,7 +856,7 @@
 
 	result =
 	    request_irq(priv->realirq, irq_handler,
-			SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev);
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (result != 0) {
 		printk("%s: failed to register irq %d\n", dev->name,
 		       dev->irq);

diff -urN linux-2.4.9-pre4/drivers/net/ne2k-pci.c linux/drivers/net/ne2k-pci.c
@@ -387,7 +387,8 @@
 
 static int ne2k_pci_open(struct net_device *dev)
 {
-	int ret = request_irq(dev->irq, ei_interrupt, SA_SHIRQ, dev->name, dev);
+	int ret = request_irq(dev->irq, ei_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (ret)
 		return ret;
 

diff -urN linux-2.4.9-pre4/drivers/net/pcmcia/pcnet_cs.c linux/drivers/net/pcmcia/pcnet_cs.c
@@ -977,7 +977,7 @@
     MOD_INC_USE_COUNT;
 
     set_misc_reg(dev);
-    request_irq(dev->irq, ei_irq_wrapper, SA_SHIRQ, dev_info, dev);
+    request_irq(dev->irq, ei_irq_wrapper, SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev_info, dev);
 
     info->link_status = 0x00;
     info->watchdog.function = &ei_watchdog;

diff -urN linux-2.4.9-pre4/drivers/net/pcmcia/xircom_tulip_cb.c linux/drivers/net/pcmcia/xircom_tulip_cb.c
@@ -768,7 +768,8 @@
 {
 	struct tulip_private *tp = (struct tulip_private *)dev->priv;
 
-	if (request_irq(dev->irq, &tulip_interrupt, SA_SHIRQ, dev->name, dev))
+	if (request_irq(dev->irq, &tulip_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev))
 		return -EAGAIN;
 
 	tulip_init_ring(dev);

diff -urN linux-2.4.9-pre4/drivers/net/sk_mca.c linux/drivers/net/sk_mca.c
@@ -861,7 +861,7 @@
 	/* register resources - only necessary for IRQ */
 	result =
 	    request_irq(priv->realirq, irq_handler,
-			SA_SHIRQ | SA_SAMPLE_RANDOM, "sk_mca", dev);
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, "sk_mca", dev);
 	if (result != 0) {
 		printk("%s: failed to register irq %d\n", dev->name,
 		       dev->irq);

diff -urN linux-2.4.9-pre4/drivers/net/smc9194.c linux/drivers/net/smc9194.c
@@ -1019,7 +1019,7 @@
 	ether_setup(dev);
 
 	/* Grab the IRQ */
-      	retval = request_irq(dev->irq, &smc_interrupt, 0, dev->name, dev);
+      	retval = request_irq(dev->irq, &smc_interrupt, SA_SAMPLE_NET_RANDOM, dev->name, dev);
       	if (retval) {
 		printk("%s: unable to get IRQ %d (irqval=%d).\n", dev->name,
 			dev->irq, retval);

diff -urN linux-2.4.9-pre4/drivers/net/tulip/tulip_core.c linux/drivers/net/tulip/tulip_core.c
@@ -504,7 +504,9 @@
 	int retval;
 	MOD_INC_USE_COUNT;
 
-	if ((retval = request_irq(dev->irq, &tulip_interrupt, SA_SHIRQ, dev->name, dev))) {
+	if ((retval = request_irq(dev->irq, &tulip_interrupt,
+					SA_SHIRQ | SA_SAMPLE_NET_RANDOM,
+					dev->name, dev))) {
 		MOD_DEC_USE_COUNT;
 		return retval;
 	}

diff -urN linux-2.4.9-pre4/drivers/net/wavelan.c linux/drivers/net/wavelan.c
@@ -3897,7 +3897,8 @@
 		return -ENXIO;
 	}
 
-	if (request_irq(dev->irq, &wavelan_interrupt, 0, "WaveLAN", dev) != 0) 
+	if (request_irq(dev->irq, &wavelan_interrupt, SA_SAMPLE_NET_RANDOM,
+				"WaveLAN", dev) != 0) 
 	{
 #ifdef DEBUG_CONFIG_ERROR
 		printk(KERN_WARNING "%s: wavelan_open(): invalid IRQ\n",

Robert M. Love
rml at ufl.edu
rml at tech9.net

against 2.4.8-ac5. patch #1 of 2 (required: adds the new define for all architectures, configure support, etc.) see previous email.

diff -urN linux-2.4.8-ac5/Documentation/Configure.help linux/Documentation/Configure.help
@@ -8594,6 +8594,19 @@
 
   If you don't know what to use this for, you don't need it.
 
+Allow Net Devices to contribute to /dev/random
+CONFIG_NET_RANDOM
+  If you say Y here, network device interrupts will contribute to the
+  kernel entropy pool at /dev/random. Normally, block devices and
+  some other devices (keyboard, mouse) add to the pool. Some people,
+  however, feel that network devices should not contribute to /dev/random
+  because an external attacker could manipulate incoming packets in a
+  manner to force the pool into a determinable state. Note this is
+  completely theoretical.
+
+  If you don't mind the risk or are using a headless system and are in
+  need of more entropy, say Y.
+
 Ethertap network tap (OBSOLETE)
 CONFIG_ETHERTAP
   If you say Y here (and have said Y to "Kernel/User network link

diff -urN linux-2.4.8-ac5/drivers/net/Config.in linux/drivers/net/Config.in
@@ -9,6 +9,7 @@
 tristate 'Bonding driver support' CONFIG_BONDING
 tristate 'EQL (serial line load balancing) support' CONFIG_EQUALIZER
 tristate 'Universal TUN/TAP device driver support' CONFIG_TUN
+bool 'Allow Net Devices to contribute to /dev/random' CONFIG_NET_RANDOM
 if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
    if [ "$CONFIG_NETLINK" = "y" ]; then
       tristate 'Ethertap network tap (OBSOLETE)' CONFIG_ETHERTAP

diff -urN linux-2.4.8-ac5/include/asm-alpha/signal.h linux/include/asm-alpha/signal.h
@@ -121,8 +121,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x40000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          1	/* for blocking signals */
 #define SIG_UNBLOCK        2	/* for unblocking signals */
 #define SIG_SETMASK        3	/* for setting the signal mask */

diff -urN linux-2.4.8-ac5/include/asm-arm/signal.h linux/include/asm-arm/signal.h
@@ -124,8 +124,20 @@
 #define SA_SAMPLE_RANDOM	0x10000000
 #define SA_IRQNOMASK		0x08000000
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.8-ac5/include/asm-cris/signal.h linux/include/asm-cris/signal.h
@@ -120,8 +120,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.8-ac5/include/asm-i386/signal.h linux/include/asm-i386/signal.h
@@ -119,8 +119,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.8-ac5/include/asm-ia64/signal.h linux/include/asm-ia64/signal.h
@@ -106,6 +106,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK          0	/* for blocking signals */

diff -urN linux-2.4.8-ac5/include/asm-m68k/signal.h linux/include/asm-m68k/signal.h
@@ -116,8 +116,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.8-ac5/include/asm-mips/signal.h linux/include/asm-mips/signal.h
@@ -111,6 +111,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x02000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK	1	/* for blocking signals */

diff -urN linux-2.4.8-ac5/include/asm-mips64/signal.h linux/include/asm-mips64/signal.h
@@ -112,6 +112,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x02000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK	1	/* for blocking signals */

diff -urN linux-2.4.8-ac5/include/asm-parisc/signal.h linux/include/asm-parisc/signal.h
@@ -100,6 +100,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK          0	/* for blocking signals */

diff -urN linux-2.4.8-ac5/include/asm-ppc/signal.h linux/include/asm-ppc/signal.h
@@ -114,8 +114,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.8-ac5/include/asm-ppc64/signal.h linux/include/asm-ppc64/signal.h
@@ -117,8 +117,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.8-ac5/include/asm-s390/signal.h linux/include/asm-s390/signal.h
@@ -127,8 +127,20 @@
 #define SA_PROBE                SA_ONESHOT
 #define SA_SAMPLE_RANDOM        SA_RESTART
 #define SA_SHIRQ                0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0    /* for blocking signals */
 #define SIG_UNBLOCK        1    /* for unblocking signals */
 #define SIG_SETMASK        2    /* for setting the signal mask */

diff -urN linux-2.4.8-ac5/include/asm-s390x/signal.h linux/include/asm-s390x/signal.h
@@ -127,8 +127,20 @@
 #define SA_PROBE                SA_ONESHOT
 #define SA_SAMPLE_RANDOM        SA_RESTART
 #define SA_SHIRQ                0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0    /* for blocking signals */
 #define SIG_UNBLOCK        1    /* for unblocking signals */
 #define SIG_SETMASK        2    /* for setting the signal mask */

diff -urN linux-2.4.8-ac5/include/asm-sh/signal.h linux/include/asm-sh/signal.h
@@ -107,8 +107,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.8-ac5/include/asm-sparc/signal.h linux/include/asm-sparc/signal.h
@@ -176,8 +176,20 @@
 #define SA_PROBE SA_ONESHOT
 #define SA_SAMPLE_RANDOM SA_RESTART
 #define SA_STATIC_ALLOC		0x80
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 /* Type of a signal handler.  */
 #ifdef __KERNEL__
 typedef void (*__sighandler_t)(int, int, struct sigcontext *, char *);

diff -urN linux-2.4.8-ac5/include/asm-sparc64/signal.h linux/include/asm-sparc64/signal.h
@@ -192,8 +192,20 @@
 #define SA_PROBE SA_ONESHOT
 #define SA_SAMPLE_RANDOM SA_RESTART
 #define SA_STATIC_ALLOC		0x80
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 /* Type of a signal handler.  */
 #ifdef __KERNEL__
 typedef void (*__sighandler_t)(int, struct sigcontext *);

Robert M. Love
rml at ufl.edu
rml at tech9.net

against 2.4.8-ac5. patch #2 of 2 (updates some drivers to use new optional random support). see previous email

diff -urN linux-2.4.9-pre4/drivers/net/3c501.c linux/drivers/net/3c501.c
@@ -410,7 +410,8 @@
 	if (el_debug > 2)
 		printk("%s: Doing el_open()...", dev->name);
 
-	if ((retval = request_irq(dev->irq, &el_interrupt, 0, dev->name, dev)))
+	if ((retval = request_irq(dev->irq, &el_interrupt,
+				SA_SAMPLE_NET_RANDOM, dev->name, dev)))
 		return retval;
 
 	spin_lock_irqsave(&lp->lock, flags);

diff -urN linux-2.4.9-pre4/drivers/net/3c505.c linux/drivers/net/3c505.c
@@ -897,7 +897,8 @@
 	/*
 	 * install our interrupt service routine
 	 */
-	if ((retval = request_irq(dev->irq, &elp_interrupt, 0, dev->name, dev))) {
+	if ((retval = request_irq(dev->irq, &elp_interrupt,
+					SA_SAMPLE_NET_RANDOM, dev->name, dev))) {
 		printk(KERN_ERR "%s: could not allocate IRQ%d\n", dev->name, dev->irq);
 		return retval;
 	}

diff -urN linux-2.4.9-pre4/drivers/net/3c509.c linux/drivers/net/3c509.c
@@ -560,7 +560,8 @@
 	outw(RxReset, ioaddr + EL3_CMD);
 	outw(SetStatusEnb | 0x00, ioaddr + EL3_CMD);
 
-	i = request_irq(dev->irq, &el3_interrupt, 0, dev->name, dev);
+	i = request_irq(dev->irq, &el3_interrupt,
+			SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (i) return i;
 
 	EL3WINDOW(0);

diff -urN linux-2.4.9-pre4/drivers/net/3c523.c linux/drivers/net/3c523.c
@@ -280,7 +280,7 @@
 
 	elmc_id_attn586();	/* disable interrupts */
 
-	ret = request_irq(dev->irq, &elmc_interrupt, SA_SHIRQ | SA_SAMPLE_RANDOM,
+	ret = request_irq(dev->irq, &elmc_interrupt, SA_SHIRQ | SA_SAMPLE_NET_RANDOM,
 			  dev->name, dev);
 	if (ret) {
 		printk(KERN_ERR "%s: couldn't get irq %d\n", dev->name, dev->irq);

diff -urN linux-2.4.9-pre4/drivers/net/3c59x.c linux/drivers/net/3c59x.c
@@ -1581,7 +1581,7 @@
 
 	/* Use the now-standard shared IRQ implementation. */
 	if ((retval = request_irq(dev->irq, vp->full_bus_master_rx ?
-				&boomerang_interrupt : &vortex_interrupt, SA_SHIRQ, dev->name, dev))) {
+				&boomerang_interrupt : &vortex_interrupt, SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev))) {
 		printk(KERN_ERR "%s: Could not reserve IRQ %d\n", dev->name, dev->irq);
 		goto out;
 	}

diff -urN linux-2.4.9-pre4/drivers/net/8139too.c linux/drivers/net/8139too.c
@@ -1289,7 +1289,8 @@
 
 	DPRINTK ("ENTER\n");
 
-	retval = request_irq (dev->irq, rtl8139_interrupt, SA_SHIRQ, dev->name, dev);
+	retval = request_irq (dev->irq, rtl8139_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (retval) {
 		DPRINTK ("EXIT, returning %d\n", retval);
 		return retval;

diff -urN linux-2.4.9-pre4/drivers/net/cs89x0.c linux/drivers/net/cs89x0.c
@@ -1057,7 +1057,7 @@
 
 		for (i = 2; i < CS8920_NO_INTS; i++) {
 			if ((1 << dev->irq) & lp->irq_map) {
-				if (request_irq(i, net_interrupt, 0, dev->name, dev) == 0) {
+				if (request_irq(i, net_interrupt, SA_SAMPLE_NET_RANDOM, dev->name, dev) == 0) {
 					dev->irq = i;
 					write_irq(dev, lp->chip_type, i);
 					/* writereg(dev, PP_BufCFG, GENERATE_SW_INTERRUPT); */

diff -urN linux-2.4.9-pre4/drivers/net/eepro.c linux/drivers/net/eepro.c
@@ -944,7 +944,8 @@
 		return -EAGAIN;
 	}
 		
-	if (request_irq(dev->irq , &eepro_interrupt, 0, dev->name, dev)) {
+	if (request_irq(dev->irq , &eepro_interrupt, SA_SAMPLE_NET_RANDOM,
+				dev->name, dev)) {
 		printk("%s: unable to get IRQ %d.\n", dev->name, dev->irq);
 		return -EAGAIN;
 	}

diff -urN linux-2.4.9-pre4/drivers/net/eepro100.c linux/drivers/net/eepro100.c
@@ -932,7 +932,8 @@
 	sp->in_interrupt = 0;
 
 	/* .. we can safely take handler calls during init. */
-	retval = request_irq(dev->irq, &speedo_interrupt, SA_SHIRQ, dev->name, dev);
+	retval = request_irq(dev->irq, &speedo_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (retval) {
 		MOD_DEC_USE_COUNT;
 		return retval;

diff -urN linux-2.4.9-pre4/drivers/net/eexpress.c linux/drivers/net/eexpress.c
@@ -433,7 +433,8 @@
 	if (!dev->irq || !irqrmap[dev->irq])
 		return -ENXIO;
 
-	ret = request_irq(dev->irq,&eexp_irq,0,dev->name,dev);
+	ret = request_irq(dev->irq,&eexp_irq,SA_SAMPLE_NET_RANDOM,
+			dev->name,dev);
 	if (ret) return ret;
 
 	request_region(ioaddr, EEXP_IO_EXTENT, "EtherExpress");

diff -urN linux-2.4.9-pre4/drivers/net/ibmlana.c linux/drivers/net/ibmlana.c
@@ -856,7 +856,7 @@
 
 	result =
 	    request_irq(priv->realirq, irq_handler,
-			SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev);
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (result != 0) {
 		printk("%s: failed to register irq %d\n", dev->name,
 		       dev->irq);

diff -urN linux-2.4.9-pre4/drivers/net/ne2k-pci.c linux/drivers/net/ne2k-pci.c
@@ -387,7 +387,8 @@
 
 static int ne2k_pci_open(struct net_device *dev)
 {
-	int ret = request_irq(dev->irq, ei_interrupt, SA_SHIRQ, dev->name, dev);
+	int ret = request_irq(dev->irq, ei_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (ret)
 		return ret;
 

diff -urN linux-2.4.9-pre4/drivers/net/pcmcia/pcnet_cs.c linux/drivers/net/pcmcia/pcnet_cs.c
@@ -977,7 +977,7 @@
     MOD_INC_USE_COUNT;
 
     set_misc_reg(dev);
-    request_irq(dev->irq, ei_irq_wrapper, SA_SHIRQ, dev_info, dev);
+    request_irq(dev->irq, ei_irq_wrapper, SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev_info, dev);
 
     info->link_status = 0x00;
     info->watchdog.function = &ei_watchdog;

diff -urN linux-2.4.9-pre4/drivers/net/pcmcia/xircom_tulip_cb.c linux/drivers/net/pcmcia/xircom_tulip_cb.c
@@ -768,7 +768,8 @@
 {
 	struct tulip_private *tp = (struct tulip_private *)dev->priv;
 
-	if (request_irq(dev->irq, &tulip_interrupt, SA_SHIRQ, dev->name, dev))
+	if (request_irq(dev->irq, &tulip_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev))
 		return -EAGAIN;
 
 	tulip_init_ring(dev);

diff -urN linux-2.4.9-pre4/drivers/net/sk_mca.c linux/drivers/net/sk_mca.c
@@ -861,7 +861,7 @@
 	/* register resources - only necessary for IRQ */
 	result =
 	    request_irq(priv->realirq, irq_handler,
-			SA_SHIRQ | SA_SAMPLE_RANDOM, "sk_mca", dev);
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, "sk_mca", dev);
 	if (result != 0) {
 		printk("%s: failed to register irq %d\n", dev->name,
 		       dev->irq);

diff -urN linux-2.4.9-pre4/drivers/net/smc9194.c linux/drivers/net/smc9194.c
@@ -1019,7 +1019,7 @@
 	ether_setup(dev);
 
 	/* Grab the IRQ */
-      	retval = request_irq(dev->irq, &smc_interrupt, 0, dev->name, dev);
+      	retval = request_irq(dev->irq, &smc_interrupt, SA_SAMPLE_NET_RANDOM, dev->name, dev);
       	if (retval) {
 		printk("%s: unable to get IRQ %d (irqval=%d).\n", dev->name,
 			dev->irq, retval);

diff -urN linux-2.4.9-pre4/drivers/net/tulip/tulip_core.c linux/drivers/net/tulip/tulip_core.c
@@ -504,7 +504,9 @@
 	int retval;
 	MOD_INC_USE_COUNT;
 
-	if ((retval = request_irq(dev->irq, &tulip_interrupt, SA_SHIRQ, dev->name, dev))) {
+	if ((retval = request_irq(dev->irq, &tulip_interrupt,
+					SA_SHIRQ | SA_SAMPLE_NET_RANDOM,
+					dev->name, dev))) {
 		MOD_DEC_USE_COUNT;
 		return retval;
 	}

diff -urN linux-2.4.9-pre4/drivers/net/wavelan.c linux/drivers/net/wavelan.c
@@ -3897,7 +3897,8 @@
 		return -ENXIO;
 	}
 
-	if (request_irq(dev->irq, &wavelan_interrupt, 0, "WaveLAN", dev) != 0) 
+	if (request_irq(dev->irq, &wavelan_interrupt, SA_SAMPLE_NET_RANDOM,
+				"WaveLAN", dev) != 0) 
 	{
 #ifdef DEBUG_CONFIG_ERROR
 		printk(KERN_WARNING "%s: wavelan_open(): invalid IRQ\n",

Robert M. Love
rml at ufl.edu
rml at tech9.net

Robert Love <[email protected]> :

Please, add an '(EXPERIMENTAL)' label to the configuration thing.

Ueimor

What is experimental about it?

Some devices already contributed to the pool, now its a configuration setting. It just toggles whether net devices can contribute. Nothing experimental there to me.

Robert M. Love
rml at ufl.edu
rml at tech9.net

Robert Love <[email protected]> :
[...]

The implicit-and-should-be-debated-in-2.5 assumption that the entropy estimate still makes sense ?

Ueimor

As opposed to the huge amount of sense it currently makes to collect it depending on your NIC manufacturer, as opposed to dependent upon a config option?

If you mean that the option should be labelled 'not for the paranoid' I agree. The patch does that. 'Experimental' means the code may crash, or perform other than as advertized.

--
Alex Bligh

amen, thank you :)

agreed.

now, we talked earlier about this patch, Alex -- what are your opinions of it? have you tried it?

i know it is not exactly what you want (although i am still open to your way, too), but i made it due in no small part to our conversation and would like your opinion. i am using it now.

Robert M. Love
rml at ufl.edu
rml at tech9.net

Looks 'obviously correct' to me (famous last words). I can't try it on the system that is otherwise entropy-short as I don't want to touch the kernel on that box right now.

As I said to you by private email, I have a slight preference for a /proc controlled version (just so vendor-distributed precompiled kernels could work either way, with the vendor-dist rc script chosing a default option based on the vendor config script) given coding /proc entries is trivial (see manual patch :-). However, your patch is many many times better than the status quo IMHO.

--
Alex Bligh

It would be interesting if an option were possible for entropy pool via loopback traffic.

D. Stimits, [email protected]

is that humor? :)

it can certainly generate a large amount of entropy if you let it.

but the general mechanism for grabbing entropy from char/net devices is measuring values from their interrupt timings. this is done via a flag value in request_irq.

loopback has no interrupts thus no request_irq

Robert M. Love
rml at ufl.edu
rml at tech9.net

then mark the entropy generator experimental if you believe that. its irrelevant here.

this is just taking a behavior that is inconsistent (do NICs enable SA_SAMPLE_RANDOM), making it consistent (SA_SAMPLE_NET_RANDOM), and making it configurable. Nothing is experimental. This does not change things; it makes things configurable.

Robert M. Love
rml at ufl.edu
rml at tech9.net

To a large degree, yes (but now that I think about it, not entirely...speculation is dangerous to one's sanity).

After hearing about all of the possible ways of sniffing keyboards, I have to wonder how hard it would be to create an irq sniffing device to aid monitoring (like the keyboard device, planted directly in the computer being monitored, though I suppose once you have the keystrokes it is a moot point). Then there are also all those wireless mice and keyboards, which could possibly broadcast useful information about irq (although knowing the exact time between irq's can only be estimated without actually tapping straight into the motherboard hardware); there is no reason to stop at simply monitoring keystrokes (would remote monitoring of wireless devices offer *useful* info on irq timings?).

I noticed add_timer_randomness depends on time between events, and that it isn't necessarily irq that matters; but irq is most likely the least predictable event to use, and nobody has bothered to implement any other random timing source to feed the function. Something else might be used as a substitute, e.g., perhaps the temperature monitor on a cpu could be used to modify a moving snapshot of loopback traffic. I don't know if the raw data from cpu temperature monitoring is available with sufficient precision (without regard to the accuracy of the value) to count on it as a source of "environment noise" that in turn, during change, can be used to trigger the equivalent of random timing. Some of the hardware crypto devices seem to use diode noise (which can make a nice microwave generator as well), perhaps temperature monitoring could be used for a lower quality version; instead of simply passing the timing of rising and falling peaks/valleys (since it wouldn't be as rapid or random as a diode noise generator), one could use that timing in conjunction with a hash on a sliding window of loopback traffic bytes (or even to act as a coefficient, and not just a timing trigger).

The general weakness with irq seems to be that (a) it isn't always occurring at a sufficient rate in systems without mouse/keyboard (and worse on diskless sytems), and (b) there is some very minor possibility that outside monitoring or influence can sway the pool or provide help to crackers (the tech to do this usefully doesn't seem to exist right now, but I wouldn't bet on it staying that way). Loopback is probably one of the largest sources of byte traffic, is not subject to irq monitoring, and does not fall down on the job for mouseless/keyboardless/headless/diskless stations. What it lacks is a truly random way of using the traffic; supposing something like temperature monitoring could be found as an alternate timing device (in place of irq), loopback could be used (or if any event that occurs in relation to loopback is random in the way that irq is, some other alternate timing event could be used). Does anyone happen to know exactly how much "noise" could be extracted from hardware temperature monitors (would it be practical)?

D. Stimits, [email protected]

i would _think_ its just too unrelated. even if we can understand the wireless transmission, the correlation between what is sent and how the IRQs are triggered is probably pretty vague.

then you have the whole issue of skew between times, etc.

yep, entropy is gathered as the difference (delta value) between different registered events. so far, irqs are used. i think the way the block devices work is seperate, too. they dont work off irqs per se (but if a block device has hardware behind it, its irqs can add entropy on top of the block device functions).

CPU temp is not a bad idea. the RNG built into the i810/i815/i820 chipsets is like your diode example -- a chip measures some sort of flucuations over the PCI bus. quantum physics says that is truly unpredictable :)

(a) is why we need more sources of entropy, like my network patch or your loopback idea

(b) is debatable. i disagree it poses any true threat to the system.

i dont think temperature probes would have that much noise. i suppose if they were precise enough you could use the least significant bits, but what really matters is how much of that precision is exported via its interface. i suppose the lsb may be useful.

what i think we really need it to audit more drivers and, of those that would be "entropic", have them contributed to the entropy pool.

Robert M. Love
rml at ufl.edu
rml at tech9.net

this is an update of my patch for 2.4.8-ac8 to allow user configuration of whether or not network devices feed the entropy pool. the following patch enables the new setting and provides configure text. a subsequent patch updates a handfull of drivers to use the new flag.

the patch works by creating a new request_irq flag, SA_SAMPLE_NET_RANDOM which defines to SA_SAMPLE_RANDOM or 0 dependening on the configuration setting (available in Network Devices). thus the patch adds no more code after compiling. for more information, see the previous emails in this thread.

obviously some people fear NICs feeding entropy provides a hazard. for those who dont, or are increadibly low on entropy, enable the configuration option.

diff -urN linux-2.4.8-ac7/Documentation/Configure.help linux/Documentation/Configure.help
@@ -8679,6 +8679,19 @@
 
   If you don't know what to use this for, you don't need it.
 
+Allow Net Devices to contribute to /dev/random
+CONFIG_NET_RANDOM
+  If you say Y here, network device interrupts will contribute to the
+  kernel entropy pool at /dev/random. Normally, block devices and
+  some other devices (keyboard, mouse) add to the pool. Some people,
+  however, feel that network devices should not contribute to /dev/random
+  because an external attacker could manipulate incoming packets in a
+  manner to force the pool into a determinable state. Note this is
+  completely theoretical.
+
+  If you don't mind the risk or are using a headless system and are in
+  need of more entropy, say Y.
+
 Ethertap network tap (OBSOLETE)
 CONFIG_ETHERTAP
   If you say Y here (and have said Y to "Kernel/User network link

diff -urN linux-2.4.8-ac5/drivers/net/Config.in linux/drivers/net/Config.in
@@ -9,6 +9,7 @@
 tristate 'Bonding driver support' CONFIG_BONDING
 tristate 'EQL (serial line load balancing) support' CONFIG_EQUALIZER
 tristate 'Universal TUN/TAP device driver support' CONFIG_TUN
+bool 'Allow Net Devices to contribute to /dev/random' CONFIG_NET_RANDOM
 if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
    if [ "$CONFIG_NETLINK" = "y" ]; then
       tristate 'Ethertap network tap (OBSOLETE)' CONFIG_ETHERTAP

diff -urN linux-2.4.8-ac7/include/asm-alpha/signal.h linux/include/asm-alpha/signal.h
@@ -121,8 +121,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x40000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          1	/* for blocking signals */
 #define SIG_UNBLOCK        2	/* for unblocking signals */
 #define SIG_SETMASK        3	/* for setting the signal mask */

diff -urN linux-2.4.8-ac7/include/asm-arm/signal.h linux/include/asm-arm/signal.h
@@ -124,8 +124,20 @@
 #define SA_SAMPLE_RANDOM	0x10000000
 #define SA_IRQNOMASK		0x08000000
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.8-ac7/include/asm-cris/signal.h linux/include/asm-cris/signal.h
@@ -120,8 +120,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.8-ac7/include/asm-i386/signal.h linux/include/asm-i386/signal.h
@@ -119,8 +119,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.8-ac7/include/asm-ia64/signal.h linux/include/asm-ia64/signal.h
@@ -106,6 +106,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK          0	/* for blocking signals */

diff -urN linux-2.4.8-ac7/include/asm-m68k/signal.h linux/include/asm-m68k/signal.h
@@ -116,8 +116,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.8-ac7/include/asm-mips/signal.h linux/include/asm-mips/signal.h
@@ -111,6 +111,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x02000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK	1	/* for blocking signals */

diff -urN linux-2.4.8-ac7/include/asm-mips64/signal.h linux/include/asm-mips64/signal.h
@@ -112,6 +112,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x02000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK	1	/* for blocking signals */

diff -urN linux-2.4.8-ac7/include/asm-parisc/signal.h linux/include/asm-parisc/signal.h
@@ -100,6 +100,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK          0	/* for blocking signals */

diff -urN linux-2.4.8-ac7/include/asm-ppc/signal.h linux/include/asm-ppc/signal.h
@@ -114,8 +114,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.8-ac7/include/asm-ppc64/signal.h linux/include/asm-ppc64/signal.h
@@ -117,8 +117,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.8-ac7/include/asm-s390/signal.h linux/include/asm-s390/signal.h
@@ -127,8 +127,20 @@
 #define SA_PROBE                SA_ONESHOT
 #define SA_SAMPLE_RANDOM        SA_RESTART
 #define SA_SHIRQ                0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0    /* for blocking signals */
 #define SIG_UNBLOCK        1    /* for unblocking signals */
 #define SIG_SETMASK        2    /* for setting the signal mask */

diff -urN linux-2.4.8-ac7/include/asm-s390x/signal.h linux/include/asm-s390x/signal.h
@@ -127,8 +127,20 @@
 #define SA_PROBE                SA_ONESHOT
 #define SA_SAMPLE_RANDOM        SA_RESTART
 #define SA_SHIRQ                0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0    /* for blocking signals */
 #define SIG_UNBLOCK        1    /* for unblocking signals */
 #define SIG_SETMASK        2    /* for setting the signal mask */

diff -urN linux-2.4.8-ac7/include/asm-sh/signal.h linux/include/asm-sh/signal.h
@@ -107,8 +107,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

diff -urN linux-2.4.8-ac7/include/asm-sparc/signal.h linux/include/asm-sparc/signal.h
@@ -176,8 +176,20 @@
 #define SA_PROBE SA_ONESHOT
 #define SA_SAMPLE_RANDOM SA_RESTART
 #define SA_STATIC_ALLOC		0x80
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 /* Type of a signal handler.  */
 #ifdef __KERNEL__
 typedef void (*__sighandler_t)(int, int, struct sigcontext *, char *);

diff -urN linux-2.4.8-ac7/include/asm-sparc64/signal.h linux/include/asm-sparc64/signal.h
@@ -192,8 +192,20 @@
 #define SA_PROBE SA_ONESHOT
 #define SA_SAMPLE_RANDOM SA_RESTART
 #define SA_STATIC_ALLOC		0x80
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 /* Type of a signal handler.  */
 #ifdef __KERNEL__
 typedef void (*__sighandler_t)(int, struct sigcontext *);

diff -urN linux-2.4.8-ac7/include/asm-x86_64/signal.h linux/include/asm-x86_64/signal.h
@@ -119,8 +119,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */

Robert M. Love
rml at ufl.edu
rml at tech9.net

Why don't those who aren't worried about whether they _really_ have enough entropy simply use /dev/urandom?

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."

So how are you going to feed /dev/urandom on your firewall ?? (which has no keyboard, program or disk activity)

Network entropy is probably better than no entropy for many applications.

Rik
--
IA64: a worthy successor to i860.

http://www.surriel.com/ http://distro.conectiva.com/

Send all your spam to [email protected] (spam digging piggy)

The network is still feeding data to the pool, yes? It's merely underestimating the value of that data. If you think you're getting enough entropy for your application, use /dev/urandom, don't weaken /dev/random.

Practically speaking, /dev/urandom is pretty damn strong anyway.

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Honestly, I don't have a clue what you are talking about. I think you have a misconception about how the entropy gathering works, the differences between /dev/random and /dev/urandom, and what entropy even is.

I don't know what your problem is with with allowing net devices to feed the pool.

Finally, /dev/random and /dev/urandom have the same "strength" -- the _only_ difference is that /dev/random will block if the _entropy_ count is 0. note, again, this is not the byte count. by design, the size of the pool does not decrement as you read from it. just the estimate of the entropy.

Robert M. Love
rml at ufl.edu
rml at tech9.net

Read it the other way around:
He fixed a bug where some network devices where feeding the pool illegally and making your system "unsecure". The "bug-fix" is configurable so you can choose for yourself, if you want to have the "old broken unsecure" bahaviour or you want to disable all entropy feeding by NICs and want your processes get stuck when reading /dev/random.

BYtE
Philipp

  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ [email protected]

Hardware random generator?

mrc

     Mike Castle      [email protected]      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

because there still is no entropy. /dev/urandom and /dev/random are from the same source - /dev/random will just block if the entropy count drops to 0. note that entropy != bytes in pool. the "entropy" is an estimate of the randomness of the pool. it decrements as bytes are pulled from the pool. the byte count does not, thus the pool is not empty when /dev/random blocks, it just has no "entropy".

on a diskless/headless system, there are no devices to feed the entropy pool. thus this patch, which is a lifesaver for some, as Rik pointed out.

or maybe you are like me, and on a personal LAN or dont care about external attackers trying to guess your /dev/random, and just want another source of entropy to boost your self-esteem.

i would like to see this in the mainline kernel. i posted a 2.4.8-pre patch early, i will rediff for 2.4.9 asap.

fyi, i am considering rewriting the patch. Alex Bligh and I had a discussion where he suggested a sysctl/proc interface to toggle the option. this would add post-compile code to the kernel, but allow greater flexibility.

Robert M. Love
rml at ufl.edu
rml at tech9.net

But your claim is there _is_ entropy. If you think there is, go ahead and use it. Via /dev/urandom. Yes, I know it's theoretically not secure, but then neither is what you're proposing.

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."

OK, you seem to have a misunderstanding about both the meaning of "entropy" and the things which have been written and proposed in this thread.

Robert, please don't let Oliver discourage you.

regards,

Rik
--
IA64: a worthy successor to i860.

http://www.surriel.com/ http://distro.conectiva.com/

Send all your spam to [email protected] (spam digging piggy)

I won't, and I appreciate your encourangement and help in this thread.

Robert M. Love
rml at ufl.edu
rml at tech9.net

I am only continuing this because I want to explain...

I claim there is entropy from what? The difference between interrupts for net devices? Everyone agrees that there is. The issues is that an external attacker could influence the interrupts to the net device, and thus make some assumptions about the state. That is why this patch is configurable. Do as you please. As I said, some people want it or need it.

Again, /dev/urandom is just as "secure" as /dev/random. Its the same pool. The same stuff. Except that /dev/random blocks when the entropy count hits 0.

Now, this count is purely theoretical, too. Its an estime of the amount of entropy -- lack of determinability -- in the pool of bytes.

Even when it reaches 0, since the pool is still unknown (only previous output may be known) and the output is hashed, its still pretty much undeterminable. But mathematically and theoretically, our entropy estimate says it is not.

Robert M. Love
rml at ufl.edu
rml at tech9.net

Perhaps the patch does this already, but if there are concerns about pollution from the nasty outside is it possible to add a flag to /proc to turn this on/off by interface - that way it could easily be limited to only get influenced by the inside network rather than the outside.

Regards,

gene/
[email protected]

Gene,

No it doesn't do this, but:

Because it looks at inter-IRQ timing, the risk is mainly (as per previous posting) the theoretical risk of being able to determine that inter-IRQ timing from observation of the network(s) connected. So an attacker sending packets at known intervals on one network when interleaved with packets arriving at unknown intervals on another network will not do them much good. Equally observations made on packet timings on one network will be useless if those packets are interleaved with packets arriving on another network. As per previous posting, there is a theoretical risk, (magnitude dependent upon environment) - hence the config option - but rather smaller than the risk (say) if you are using a radio mouse & keyboard.

--
Alex Bligh

So I looked at this a bit more. The stuff which increases entropy is meant to be secure from non-root users.

However (standard debian install - headless machine), unpriveleged account:

$ cat /proc/interrupts
          CPU0
 0: 1116302985          XT-PIC  timer
 1:          2          XT-PIC  keyboard
 2:          0          XT-PIC  cascade
 8:          1          XT-PIC  rtc
 9:   28980016          XT-PIC  usb-uhci, eth0
14:  698146587          XT-PIC  ide0
15:          5          XT-PIC  ide1
NMI:          0
ERR:          0

Shock horror - I can continually poll this and spot when an IRQ occurs.

So polling /proc/interrupts gives me a pretty good indication of timing for ide0 interrupts (and, if I had one, keyboard interrupts). The /proc reading routine is sufficiently fast that by repeating reading (as a user) I should be able to get the inter-IRQ timing down to a few tens of microseconds, which I think is a few tens of possible values added to the entropy pool. This tells me that actually keyboard and ide interrupt timings are no less observable by non-root people than network interrupts.

Now if you have an IR or radio keyboard, the situation is even worse.

So I don't think Robert's patch is any more flawed than using k/b, mouse, ide IRQs.

--
Alex Bligh

& (as per add_timer_randomness) on all non-i386's and some i386's, I actually only need to get the time within one jiffy. Do this on 4 successive IRQ's, and that's 12 bits of 'false' entropy. But the point is, it's no worse for network than for the rest.

--
Alex Bligh

To what level of accuracy do you think you can measure when interrupts
occur? From my tests, you can (if you max the processor and do no math on the results) read /proc/interrupts about once every 30,000 instruction cycles. This would still leave about 14 bits of entropy in each interrupt.

Overall, you're just making the system busier.

DS

Better than the necessary 1 jiffie on non-i386 platforms and some i386 platforms.

--
Alex Bligh

On those platforms, you simply can't have good entropy and still have user
accounts on the box with the default hardware. Sorry, the hardware just doesn't permit it. You would have to set up some secure way to draw entropy off an external pool, there's just nothing else you can do. (I believe there are non-x87 platforms that have good timers, just not all of them.)

DS

Many non-i386 platforms have more finely grained timers than 1 jiffie. The problem is the code doesn't use them. So my point is, it seems illogical to throw stones at (often) theoretical issues with Robert's patch, when people's energy would be better diverted to help fix up hole in the current implementation.

--
Alex Bligh

I don't understand the connection. Either Robert's patch is good or it's
bad. If there are other problems, then we can address those too. But to say that Robert's patch is bad because it doesn't fix the most important problem that you can think of doesn't make any sense. Every problem should be fixed, and if Robert has a patch to fix one of them, then that's one less.

You can certainly advise people to work on the most serious problems. But
you most certainly can't say that someone shouldn't work on X because Y is more important.

DS

David,

For clarity, I'm saying Robert's patch is GOOD, and those who are trying to point out what I consider to be extremely theoretical weakness it introduces into /dev/random (and then, only when config'd on), should instead spend their attention looking at miuch more serious issues in the algorithm elsewhere if they are that worried, rather than attacking something which is useful.

To make an analogy, Robert is suggesting changing the 9 cylinder lock on the back door of a house to a 7 cylinder lock, which is much easier to operate, but perhaps slightly less secure. (well, to be precise, he's advocating giving the house own the OPTION to do this). However, the front door is wide open, swinging in the wind, with no lock on at all. And people are worried about Robert's patch. Doesn't make much sense...

--
Alex Bligh

so as I see this discussion it goes something like this.

1. the entropy pool is not large enough on headless machines.
2. you don't want to use urandom as there are theoretical attacks against it

so as a result you propose adding an option to weaken random (network traffic is not that random which is a large part of why it's not included now)

you are trading one theoretical attack for another known attack (a difficult attack to pull off yes, but still known)

that doesn't sound like a reasonable tradeoff to me.

as for the arguments that applications all use random and would have to be changed to use urandom.

don't forget that it's not the names that matter to the kernel it's the major/minor numbers. you can rename random to really.random and urandom to random and your software will not know the difference.

if you were arguing that the network traffic was truly random and that it should be added in as well that would be a different story, but you're not saying that you just don't want the incomvienience of blocking while waiting for truely random data but want to fool yourself into thinking that you are.

David Lang

David,

An option, yes.

Not exactly, because to break /dev/random (with the config option on) you have to (a) do the work that would have broken /dev/urandom, and
(b) break the translation of network traffic into entropy. If you were using /dev/urandom only, you'd have to just do (a). IE if the two alternatives are /dev/urandom, and /dev/random with Robert's patch, the latter is certainly more secure (i.e. it's not a tradeoff).

This is a fair point, but doesn't take into account the 'waiting for sufficient entropy' point - which of course relies on network traffic timing being sufficiently unobservable that it constitutes valid entropy.

Well, I was arguing that network traffic was sufficiently unobservable that it constitutes valid entropy under some circumstances, until I went and read the code. It is so (it seems to me) on some i386 versions, where the cycle clock is used. It is definitely not (and neither are any of the other interrupt timings) where jiffies are used, for a start because /proc/interrupts gives you the jiffie count (timer interrupts) and the other interrupt counters simultaneously. So my argument is that in some situations (where you know are happy with the extent to which there is no observation of your wire locally), net IRQs are no worse than the other sources of entropy, and sometimes they are better (consider keyboards connected by radio). Obviously, in cases like 802.11, they are substantially worse (and, no doubt, we could omit Robert's patch from things like 802.11 drivers which are obvious 'don't do that' cases).

--
Alex Bligh

How about improving that with something like this (not test compiled)

static void add_timer_randomness(struct timer_rand_state *state, unsigned num)
{
__u32 time;
__s32 delta, delta2, delta3;
int entropy = 0;

#if defined (__i386__)
if ( test_bit(X86_FEATURE_TSC, &boot_cpu_data.x86_capability) ) {
__u32 high;
__asm__(".byte 0x0f,0x31"
:"=a" (time), "=d" (high));
num ^= high;
} else {
time = jiffies;
}
#else
+ struct timeval tv;
+ do_gettimeofday(&tv);
+ num ^= tv.tv_usec;
time = jiffies;
#endif

Of course do_gettimeofday() is probably a little to heavyweigt for doing this,
so how about adding an arch specific macro:
GET_JIFFIES_USEC()
that returns the number of microseconds in the current jiffie and simply use that to modify the num?

/Johan

If that's the concern, then I'm glad to say that I have very reassuring news for you. No attacks are known on /dev/urandom, not even theoretical ones.

(And no attack is known on SHA-1, not even a theoretical one.)

(Don't confuse a remote risk that someone might discover a theoretical attack on SHA-1 with knowledge that we already know of a theoretical attack on SHA-1.)

This is because there are no known attacks are SHA-1.

Right.

Responding to David Lang, #1 is correct. On a headless or diskless machine, the entropy pool can be very small. Net devices provide the needed entropy.

Thus, since _you_ trust SHA-1, if you also feel the bits garnered from your network interfaces is entropic, then the patch is useful for you.

If you don't, then don't enable it. But, since you trust SHA-1, /dev/random is of no difference to you than /dev/urandom, so its no difference :)

Robert M. Love
rml at ufl.edu
rml at tech9.net

That's one place where we disagree. Over-estimating entropy is not a theoretical weakness: this is something that real cryptographers get real worried about. It's one of the easiest ways for a crypto system to fail.

Entirely agreed, but that is why we have SHA-1. If we assume SHA-1 is not crackable, then the entropy estimate is actually worthless. It exists because of the theoretical possibility of learning some state of the pool from a given read.

In theory, we dont need both SHA-1 hash and the entropy count. They exist to pacify a theoretical weakness in each.

Now, my net device patch should only be enabled in situations where both you trust SHA-1 (and I think most do) and you trust that reading net devices yields the full amount of entropy.

Robert M. Love
rml at ufl.edu
rml at tech9.net

'lil typo on my part. actually, if you trust SHA-1, it does not matter if your net devices give zero entropy, because the SHA-1 hash of the read from /dev/random is still unpredictable.

the problem is if you both _dont_ trust SHA-1 and _fear_ there is less-than-estimated entropy from net devices on your network.

per Alex Bligh's suggestion, the Configure wording of the next patch will explain this.

Robert M. Love
rml at ufl.edu
rml at tech9.net

No, everyone does not agree. Entropy is the degree to which data is unpredictable. If an attacker can know what's being added to the pool, its entropy value is zero.[1]

My understanding is that net devices are still mixing data into the pool, but with an entropy estimate of zero. This seems perfectly fair to me, it's always safe to underestimate entropy. If they're not mixing data into the pool at all any more, then that seems wrong to me - we should be adding likely sources of entropy as well, even if we can't rely on them enough to credit them.

The 'except' is the key difference. IFF the entropy estimate is correct (less than or equal to the real entropy present in the pool), then the data return by /dev/random is completely unknowable. /dev/urandom is still quite strong cryptographically, but not 'perfect' (ignoring possible bugs, of course).

What you're suggesting is weakening that model. If you care enough to use /dev/random instead of /dev/urandom because of the -theoretical- security differences, then you're actually concerned about attackers. Namely attackers who can go after your network, perhaps taking over your routers and gateways. By making /dev/random mark network data as real entropy, you are just fooling yourself. The 'perfect' quality of /dev/random is lost, and the theoretical difference between it and /dev/urandom vanishes.

So why go to the trouble? Just admit that you don't have enough real entropy on your system and, if you find the risk acceptable, use /dev/urandom. Adding a kernel option that says 'make /dev/random be overconfident' is not the answer.

[1] The extent to which an attacker can mount a timing attack against the interrupt generation on a fast NIC is unknown but we'd prefer not to be surprised.

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."

..which appears to be wrong.

What we really need is an add_untrusted_randomness().

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."

This discussion is getting nowhere.

Oliver Xymoron in litteris <[email protected]> scripsit:

<...>

<...>

There is no such thing as "real" entropy. Even in thermodynamics there is no such thing as "real" entropy. All entropy is relative to some knowledge base. It does not make any sense to say "the entropy pool contains so-and-so-many logons of entropy". For a user who can read the kernel memory, the entropy of the pool is 0 at all times. For a user who has not come into contact with the box, the entropy is 4096 logons (assuming the pool's size is 4096 bits) when contact is initiated, and drops by *at most* 8 logons for every bit that is read from /dev/random - but it is not the state of /dev/random itself which changes, nor its "absolute" entropy (there is no such thing), it is only its entropy relative to a certain knowledge base.

Now the kernel makes some very conservative assumptions about the knowledge base and evaluates the corresponding entropy. It assumes, for example, that all outputs of /dev/random are fed to the same knowledge base. That is, it maintains only one entropy count (rather than, e.g., one per process). This is necessary for simplicity and security in all cases, but in some cases it may be a tremendous underestimate of the amount of entropy. Similarly, it assumes that every byte that is produced by /dev/random (or /dev/urandom) decreases the entropy count by 8 logons. This is also a conservative assumption; if a program uses only, say, the values it reads mod 26, then every byte spills only 4.7 logons (relative to the knowledge base of an observer who can only read those mod 26 values). Finally, the kernel assumes that the knowledge base of the observer contains the mean value and standard deviation and various similar statistical moments of various "entropy sources", but not their actual contents; and a choice has been made among those entropy sources.

These are very sensible assumptions, but these are assumptions nonetheless. It is utterly na�ve to think that the entropy count maintained by the kernel is the "real entropy count" of the pool, in some physical sense. For most useful knowledge bases, the kernel tremendously *underestimates* the entropy of the pool; in fact, we might say that for all "useful purposes", the entropy is infinite at all times. Supposing it is not means we suppose at least that the observer can crack the hash function used for stirring the pool, which is not at all an obvious task.

But the kernel might also overestimate the entropy count. As I mentioned before, for someone who can break root in the box, the entropy is zero at all times. For someone who can monitor electrical fluctuations with great enough accuracy, the entropy is not as high as it may seem. Also, the assumption made that the added entropy can be estimated (for timer events) using the first three deltas of the event's timing, can fail in certain circumstances (and not very nasty or unreasonable circumstances: if the event occurs at intervals which follow a cycle of length at least five, you are adding a bounded amount of entropy to the pool relative to a user who knows this fact, even if you let the event feed the pool for an arbitrarly long time, but the kernel will assume that you are, indeed, feeding it boundless amounts of entropy; so a simple 5-periodic event will cause the kernel's estimations to fail miserably).

The morale of all this is: the /dev/random device is a useful service, because the kernel does a pretty good job of producing very pure random numbers. But it is not utterly fail-safe. It nearly always underestimates the entropy (for what you're concerned with), and it may overestimate it.

Thus, if you have specific knowledge about your system, it makes perfect sense to adjust the entropy evaluation. For example, if you know that the observers you're concerned about (those against whom you use the random numbers) cannot observe your network devices (e.g., if your network device is connected to a local network and you are using the random numbers across the Internet), it is perfectly reasonable to add network devices in the estimation of the entropy count. It does not make it any less secure. It merely does not underestimate the entropy as much.

But all this is completely theoretical, anyway. Even if your life is at stake, you can be completely confident that nobody can predict the next 64 bits that are going to come out of /dev/urandom, even if you give that would-be-predictor the previous 64kbytes that did come out of it, and even if you removed *all* the entropy sources from the system.

     David A. Madore
    ([email protected],
     http://www.eleves.ens.fr:8080/home/madore/ )

Robert,

                         ^^^^^^^^^

Actually, to be fair, the true risk is more that an external attacker could /obvserve/ the timing of packets to the NIC with sufficient accuracy to predict the inter-IRQ timing, and hence the consequent manipulation of the pool. This would mean that entropy was being added, (assuming a system free of entropy to start with), eventually causing /dev/random not to block, and thus, short of any other entropy, the net effect would be that /dev/random would become exactly as good/bad a random number source as /dev/urandom. However, in most environments, it is not possible to observe and accurately (microseconds) time the packet coming into the NIC without physical access to the machine (in which case there are, urm, easier attacks), and there is a largely indeterminable latency between the arrival of the packet and the consequent network IRQ, this latency being neither externally visible, nor being determinable by some non-root user.

--
Alex Bligh

Then add another factor to the equation, randomly pick the next event.

Consider if you would, gather entropy by choosing random bytes from checksums from random packets. All the selection isn't technically random but very uncontrolled. You start by picking a random packet (seeded from existing entropy), and take a random byte from the checksum of that packet. Using that byte, add it to the entropy pool and use it to help determine the next 'random' packet you'll swipe data from.

An attacker would have to have absolute control over the packets arriving at the machine to have a chance. He still cannot know exactly which packets are chosen for entropy gathering being that the next packet is chosen randomly from two or more entropy sources. Neither will he know which byte(s) in the checksum are chosen.

In real world situations you should have a plentiful source of 'noise'. The above idea can be improved upon significantly I'm sure.

David

I think you are just wrong - nobody really needs this patch. /dev/random or /dev/urandom ar *both* anyway just complete overkill in terms of practical security. /dev/urandom is in esp silly, since it is providing a md5 hash
implementation inside the kernel, which could be *compleatly* and entierly
done inside user land.

Wrong. Don't let you confuse yourself by the way the term entropy is used in
the documentation of /dev/random - it's an abuse of the mathematical definition anyway. The more appriopriate term there
would be: signal source variability estimate.

You mean - there is no known algorithm with polynomial time behaviour enabling us to calculate the next value of this function from the previous ones - Not more nor less - no pysics and entropy involved. If you assume this holds true it's mathematically entierly sufficient that a single only seed value is not known.

and

And I think you are wrong, this patch is needed. Keep up the good work Robert!

Where would you get the single seed from in an embedded head less system if you don't have a hardware random generator, no disk and don't seed it from the network interrupts?

I think the patch makes sense - let people have the config option.

/Johan

I will -- thank you for the words. :)

exactly. this thread has gone off on a tangent arguing the very merits of /dev/random itself. obviously if you dislike the kernel's entropy gatherer, this patch won't sit well either.

the proper argument is, assuming that /dev/random is A Good Thing, is this patch useful? since its configurable, its not forcing any policy. since it can be argued pretty strongly that more entropy is needed on a headless and/or diskless, I think some people need it. personally, it boosts my self-esteem to have another source of entropy (my 3c905). if you are worried of the threats net devices have to your entropy, by all means -- dont enable the config setting.

hopefully we can get the patch merged, if for nothing else for 2.5.

Robert M. Love
rml at ufl.edu
rml at tech9.net

The device get's powerd up at a random time for the attacker. That's entierly sufficient if you assume that your checksum function f(i) hat the property that there is no function g, where we have f(i+1)=g(f(i)), where g has a polynomial order over the time domain. i is unknown for the attacker.

So, your argument is that there is no point in all this entropy collection anyway. So if everything is hunky dory, why have /dev/random block under such a circumstance? (which was the original poster's problem).

--
Alex Bligh

You are entierly right.

The primary reson of invention of /dev/random was the need for a bit of salt to the initial packet sequence number inside the networking code in linux. And for this purspose the whole /dev/*random stuff is INDEED a gratitious overdesign. For anything else crypto related it just doesn't cut the corner. If you look at the archives I have objected it strongly in the history.

isnt that the case?

also, its not even that g completes in polynomial time. its that g is not algorithmic at all.

Robert M. Love
rml at ufl.edu
rml at tech9.net

That simply isn't true. The original reason that I wrote the /dev/random driver is that was for crypto key gneration. The primary use environment was to provide better key generation routines for user applications such as PGP, etc., which is the first devices that I implemented for entropy collection was the keyboard and mouse devices.

The use of the /dev/random code for other purposes (generating initial packet sequence numbers for networking, generating a unique boot-session identifier which was requested by the emacs folks, etc.), all came later.

A number of other people helped me with the design and development of the /dev/random driver, including one of the primary authors of the random number generation routines in PGP 2.x and 5.0. Most folks feel that it does a good job.

- Ted

Indeed. If Martin has some deep insight as to why the /dev/random implementation is insufficient for strong crypto, I'd like to hear it.

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

It does :)

Thank you for adding to this thread. I want your opinion: as the author of /dev/random, its your turf. What do you think of the patch? It has been posted for various kernel versions, the newest patches are at
http://tech9.net/rml/linux

Obviously there is a theoretical risk, that is why it is configurable. Is the need or the practical risk sufficient that the patch is useful? I have gotten a lot of positive feedback.

If the patch were to be merged into the kernel, would you like anything changed? Would a /proc interface be useful (this would add overhead, right now there is zero extra code after compile)? What about changing the entropy estimate to reflect the possible less entropy from net devices?

Personally, I like the patch as is, but these have been issues raised.

Robert M. Love
rml at ufl.edu
rml at tech9.net

I don't think that it's unsufficient. In fact I think that it just doesn't
have to be done all inside the kernel. And I oppose further extending the
places where the event gathering code goes in between.

BTW> There is one strong flaw in the resoning behing this whole entropy stuff.

Iff you trust the cryptographic algorithm for the one way function you are
using then if you initialize it once - there will be only one chance for an attacker to tamper with the values. The possibility
for tampering with it will have a certain value, which remains CONSTANT over
the time. You could call it: breaking risk as well.

If you continuously reinitialize your one way function, the propabilitie to
tamper with them will ADD (of course not in pure arithmetic terms). An attacer simply
get's multiple chances. And therefore the overall propability of tampering
with the values delivered to the user by this device WILL INCREASE.

Multiple initializations help only against cryptographic attacks - but THEY HURT
overall security of the system, becouse they "open it up".

So this is indeed a serious FLAW inside the logics behind the implementation of this device.

This is inconsistent with your earlier comment "for anything else crypto related it just doesn't cut the corner". So are you retracting that statement?

I'm fairly confident that a user on the system can't tamper with my mouse movements and keyboard presses. As for other interrupt sources (such as network, disc and so on) which may be vulnerable to "tampering" (i.e. injection or monitoring of timing data), that's why we have the concept of "entropy". Think of it as a measure of trust.

This is a completely flawed argument. The more entropy inputs there are, the harder it is for an attacker to predict or control all of them.

This doesn't make sense. If, as you say, something is better against cryptographic attacks, then the overall security of the system is better. A trivially obvious example is TCP.

The flaw is in your argument, which isn't logical, and uses hand-waving in place of coherent step-by-step analysis of how /dev/random is somehow harmful to security. Use of a few choice words in uppercase isn't convincing. Furthermore, you talk about a risk to system security, but you don't even clearly define what you mean be that.

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

extending

As Alex said, since applications expect it to be there I see no reason to remove it.

for

Since the boot process is predictable, it would be much easier for an attacker to set up an identical setup and it would be no problem at all to predict the random sequence. Then it would probably be easy to do a DoS attack forcing the system to reboot and then break in.

This sounds bogus to me..;-)
I don't buy it!

/Johan

Either I completely misunderstood what you are trying to say, or your claim is simply not true. I've done considerable research on generating randomness for cryptography, and I think you're a little confused about how /dev/{,u}random work and about their cryptographic properties.

Perhaps true, but for some systems, the time it takes for a certain application that need some random data to start is the same at each powerup (more or less) so the application might use the same session key the first time after each powerup.
(Not that gathering info from network interrupt necessarily would improve this case, but it might)

Can't say I know the details of the functions used in the /dev/[u]random functions to say if that assumption is true. But I feel that stiring the pool using interrupt timing and thus adding the number of unknowns can't be a bad thing.
Simply relying on the uptime would make it really easy to predict the f() function wouldn't it?

/Johan

You have been repeating that there is no difference in security between /dev/random and /dev/urandom, but consider this: you install a kernel/hardware combination without any registered SA_SAMPLE_RANDOM IRQs (i.e. headless, no IDE, no NICs with SA_SAMPLE_RANDOM IRQs). This configuration is not hard to imagine for, say, a dedicated server appliance or embedded device.

The entropy pool for such a system starts at 0s, unless I'm misreading the source; from create_entropy_store():

        memset(r->pool, 0, poolwords*4);

As long as no interrupt ever adds randomness to this pool, I might be able to predict every bit ever read from /dev/random on this machine. I don't need to break SHA-1, I just run the algorithm forward from its starting point. I guess I would probably have to know the size of each read, so in practice an active network (TCP initial sequence numbers) in combination with other reads would make my job harder. But it's still a scary scenario. And it comes from the fact that although /dev/urandom is a strong PRNG, it is still deterministic, and if I know its complete state at any point and can simulate subsequent events, I can predict its behavior.

/dev/random is very good for making sure you never generate a GPG key on a machine like this. I agree with most people on this thread that session keys are usually safe coming from /dev/urandom. But you should still make sure you have at least one device feeding into the entropy pool, something I'm sure many admins have no clue about and don't verify.

miket

You are correct, it starts at zero. Although, you are _supposed_ to seed the pool with entropy from the previous session (save/restore entropy on shutdown/boot). All distributions I know do this correctly. Obviously, however, this is not possible in your scenerio (no disks and no entropy anyhow to save).

In this case, you are right. Maybe I am unclear, I like /dev/random and I like the entropy estimating algorithm. There is just a lot of confusion about how the entropy pool works and the differences between /dev/random and /dev/urandom, and it is true that given that SHA-1 is unbreakable /dev/random and /dev/urandom are alike in most respects.

In your situation, though, it is not ever safe to use the entropy pool period, since no entropy is generated. I am not sure if /dev/urandom would even return.

The solution to this is easy: get something to generate entropy (like my netdev patch! :) and save/restore the entropy seed.

Agreed. Personally, I always just use /dev/random for stuff I feel needs true security. It is important that sysadmins know that something is generating entropy. Ideally, it comes from numerous places. One of those places can certainly be your network devices if you trust them.

Robert M. Love
rml at ufl.edu
rml at tech9.net

Mike,

(& no access to any block devices - but leave that for the time being)

You would read precisely 0 bits from /dev/random, as it would sit there blocking, with no entropy in the system. You would be able to predict the bits from /dev/urandom. Both pretty useless for generating useful random numbers, but the blocking behaviour is probably safer.

This is the 'seeding' problem we refer to. After you've seeded the random number generator (perhaps provide some entropy from a file from the last boot), you wouldn't have this problem. And /dev/urandom and /dev/random stay the same.

The suggestion of counting various events which are 'reasonably unpredictable' but potentially observable, but not count them as entropy, helps the seeding problem. Noone has argued that using network IRQs to add randomness to the pool, but NOT count as entropy, would be bad.

If they have none, they will know it very soon, as /dev/random will block. It is currently hard to boot without accessing block devices, however (and yes, on a duplicated machine, with embedded hardware with predictable timing and no moving parts, this isn't much of an entropy source either).

--
Alex Bligh

So we then have two options, one of which is required if we are going to be able to get any random numbers from this box:

1) if we contact some server to boot or to mount filesystems, we can also slurp up some seed values from that server.
2) we enable all NIC drivers to collect entropy

In the case you describe, I don't see any other options. Without one of these paths, /dev/random will block, and /dev/urandom will be predictable.

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]

Agreed, I don't think the netdev patch is a bad idea, and it's helpful in the case I described. I was just getting worried about the assertions (from various directions) that /dev/random and /dev/urandom are practically indistinguishable unless you can break SHA-1. There's enough confusion out there as it is :-).

miket

This is not the issue; some of use _are_ worried whether or not we have enough entropy (and want a read that blocks until sufficient additional entropy arrives if entropy is insufficient), but don't have sources of enough sources of entropy (e.g. on an idling machine where everything is cached) if one does not allow network IRQ's to generate entropy. In doing the latter, we do (admittedly) make the assumption that they are valid sources of entropy (see discussion past as to why this might or might not be the case), but using /dev/urandom rather /dev/random will ALWAYS give a less random result in low entropy situations.

IE I want to use the entropy calcs; I consider network IRQ spacing to be sufficiently random and unobservable for them to be a valid source of entropy, and (as the advantages doing so for various configs have been widely documentated elsewhere) think that there should be a config option (or /proc option) to support this. I do /not/ want to ignore entropy calcs entirely (i.e. use /dev/urandom).

--
Alex Bligh

If you are that worried, shouldn't you be using a hardware generator?

mrc

     Mike Castle      [email protected]      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Mike,

(off list - as I've posted this elsewhere)

You could say the same thing to anyone who uses /dev/random rather than /dev/urandom. Why use /dev/random when it can block (inconvenient) instead of a h/w random number generator?

I'm sufficiently concerned that I want to have some 'external' entropy, and on the machine in which it is causing me problems, in an idle state, there is no other entropy source, but lots of network activity which I trust can't be snooped on.

The machine was bought and tested in one config. A hardware random number generator is something else to go wrong, and additional expense.

Using an entropy estimate which includes network event timings is no[1] worse (in this situation) than using (say) IDE interrupt timings. And no better. It certainly isn't as good as using an external random number generator. However, it is better than using /dev/urandom and leaving the kernel unpatched (see previous analysis). It's a trade-off. But if we can make (depending on circumstance) the OS (s/w) perform better with given h/w, that sounds like a good thing to do to me.

[1]=certainly not a lot worse.

--
Alex Bligh

And making a change to the kernel is not a different config?

I would argue that is just as dangerous as changing the hardware configuration.

mrc

     Mike Castle      [email protected]      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

In the very strict QA'ing sense, yes. Any sort of change whatsoever is a different config and throws out all of the other testing results. Which still leaves the cost argument in this case. But, there are degrees of how dangerous a change can be. From my quick skimming of this code, it looks like the only changes are to mark network irq bits as possible entropy. Nothing more. I could be totally wrong of course. :)
Therefore, it's quite probable anyhow that this config won't have any more problems that the other config had. Of course the only way to prove this is much QA'ing.

Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Robert Love <[email protected]> :
[...]

I have checked again the patches and they allow a lot of drivers to feed the entropy pool that otherwise wouldn't had ever contributed to it. Thus it changes things and opens the question about the effects on entropy estimate. See the figures, three (3) nics to date reference SA_SAMPLE_RANDOM. As the fact that 2.4 is supposed to be a stable serie, I assume it's irrelevant.

Ueimor

It only changes things if you configure it on, and you are correct that many other drivers feed the entropy pool if so. That is, indeed, the whole point of the patch.

There is a leap of logic in the last sentence I don't understand. Stable (or rather release) kernels are supposed to behave predictably. Behaviour dependent upon NIC is not predictable. Behaviour dependent upon a config option (which does 'exactly what it says on the tin') is predictable. Stable/release series are meant to have bugs fixed. Please tell me why having 3 NIC cards behave one way, and the rest behaviour another is /not/ a bug. Stable kernels are meant to be functional and secure. Robert's patch allows the user both/either, in situations where the previous kernel could be either dysfunctional (insufficient entropy) or arguably potentially insecure (theoretical possibility of external manipulation of entropy source).

--
Alex Bligh