[PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Chris Peterson]

I know Jeff Garzik says he's not interested in an anti-entropy pogrom for existing net drivers, but here is the patch if anyone else is interested..? :)

Only 12 net drivers are affected, the last of the theoretically-exploitable network entropy.

drivers/net/3c523.c
drivers/net/3c527.c
drivers/net/atlx/atl1.c
drivers/net/cris/eth_v10.c
drivers/net/ibmlana.c
drivers/net/macb.c
drivers/net/mv643xx_eth.c
drivers/net/netxen/netxen_nic_main.c
drivers/net/niu.c
drivers/net/qla3xxx.c
drivers/net/tg3.c
drivers/net/xen-netfront.c

chris


Signed-off-by: Chris Peterson <cpeterso@cpeterso.com>
---
diff -uprN linux-2.6.26-rc2-git3.orig/drivers/net/3c523.c linux-2.6.26-rc2-git3/drivers/net/3c523.c
--- linux-2.6.26-rc2-git3.orig/drivers/net/3c523.c	2008-05-13 22:37:06.000000000 -0700
+++ linux-2.6.26-rc2-git3/drivers/net/3c523.c	2008-05-13 23:11:58.000000000 -0700
@@ -289,8 +289,7 @@ static int elmc_open(struct net_device *
 
 	elmc_id_attn586();	/* disable interrupts */
 
-	ret = request_irq(dev->irq, &elmc_interrupt, IRQF_SHARED | IRQF_SAMPLE_RANDOM,
-			  dev->name, dev);
+	ret = request_irq(dev->irq, &elmc_interrupt, IRQF_SHARED, dev->name, dev);
 	if (ret) {
 		printk(KERN_ERR "%s: couldn't get irq %d\n", dev->name, dev->irq);
 		elmc_id_reset586();
diff -uprN linux-2.6.26-rc2-git3.orig/drivers/net/3c527.c linux-2.6.26-rc2-git3/drivers/net/3c527.c
--- linux-2.6.26-rc2-git3.orig/drivers/net/3c527.c	2008-05-13 22:37:06.000000000 -0700
+++ linux-2.6.26-rc2-git3/drivers/net/3c527.c	2008-05-13 23:12:15.000000000 -0700
@@ -434,7 +434,7 @@ static int __init mc32_probe1(struct net
 	 *	Grab the IRQ
 	 */
 
-	err = request_irq(dev->irq, &mc32_interrupt, IRQF_SHARED | IRQF_SAMPLE_RANDOM, DRV_NAME, dev);
+	err = request_irq(dev->irq, &mc32_interrupt, IRQF_SHARED, DRV_NAME, dev);
 	if (err) {
 		release_region(dev->base_addr, MC32_IO_EXTENT);
 		printk(KERN_ERR "%s: unable to get IRQ %d.\n", DRV_NAME, dev->irq);
diff -uprN linux-2.6.26-rc2-git3.orig/drivers/net/atlx/atl1.c linux-2.6.26-rc2-git3/drivers/net/atlx/atl1.c
--- linux-2.6.26-rc2-git3.orig/drivers/net/atlx/atl1.c	2008-05-13 22:38:11.000000000 -0700
+++ linux-2.6.26-rc2-git3/drivers/net/atlx/atl1.c	2008-05-13 23:13:00.000000000 -0700
@@ -2614,7 +2614,7 @@ static s32 atl1_up(struct atl1_adapter *
 {
 	struct net_device *netdev = adapter->netdev;
 	int err;
-	int irq_flags = IRQF_SAMPLE_RANDOM;
+	int irq_flags = 0;
 
 	/* hardware has been reset, we need to reload some things */
 	atlx_set_multi(netdev);
diff -uprN linux-2.6.26-rc2-git3.orig/drivers/net/cris/eth_v10.c linux-2.6.26-rc2-git3/drivers/net/cris/eth_v10.c
--- linux-2.6.26-rc2-git3.orig/drivers/net/cris/eth_v10.c	2008-05-13 22:37:10.000000000 -0700
+++ linux-2.6.26-rc2-git3/drivers/net/cris/eth_v10.c	2008-05-13 23:14:19.000000000 -0700
@@ -490,7 +490,7 @@ e100_open(struct net_device *dev)
 	/* allocate the irq corresponding to the receiving DMA */
 
 	if (request_irq(NETWORK_DMA_RX_IRQ_NBR, e100rxtx_interrupt,
-			IRQF_SAMPLE_RANDOM, cardname, (void *)dev)) {
+			0, cardname, (void *)dev)) {
 		goto grace_exit0;
 	}
 
diff -uprN linux-2.6.26-rc2-git3.orig/drivers/net/ibmlana.c linux-2.6.26-rc2-git3/drivers/net/ibmlana.c
--- linux-2.6.26-rc2-git3.orig/drivers/net/ibmlana.c	2008-05-13 22:37:29.000000000 -0700
+++ linux-2.6.26-rc2-git3/drivers/net/ibmlana.c	2008-05-13 23:14:54.000000000 -0700
@@ -783,7 +783,7 @@ static int ibmlana_open(struct net_devic
 
 	/* register resources - only necessary for IRQ */
 
-	result = request_irq(priv->realirq, irq_handler, IRQF_SHARED | IRQF_SAMPLE_RANDOM, dev->name, dev);
+	result = request_irq(priv->realirq, irq_handler, IRQF_SHARED, dev->name, dev);
 	if (result != 0) {
 		printk(KERN_ERR "%s: failed to register irq %d\n", dev->name, dev->irq);
 		return result;
diff -uprN linux-2.6.26-rc2-git3.orig/drivers/net/macb.c linux-2.6.26-rc2-git3/drivers/net/macb.c
--- linux-2.6.26-rc2-git3.orig/drivers/net/macb.c	2008-05-13 22:37:32.000000000 -0700
+++ linux-2.6.26-rc2-git3/drivers/net/macb.c	2008-05-13 23:15:17.000000000 -0700
@@ -1151,8 +1151,7 @@ static int __init macb_probe(struct plat
 	}
 
 	dev->irq = platform_get_irq(pdev, 0);
-	err = request_irq(dev->irq, macb_interrupt, IRQF_SAMPLE_RANDOM,
-			  dev->name, dev);
+	err = request_irq(dev->irq, macb_interrupt, 0, dev->name, dev);
 	if (err) {
 		printk(KERN_ERR
 		       "%s: Unable to request IRQ %d (error %d)\n",
diff -uprN linux-2.6.26-rc2-git3.orig/drivers/net/mv643xx_eth.c linux-2.6.26-rc2-git3/drivers/net/mv643xx_eth.c
--- linux-2.6.26-rc2-git3.orig/drivers/net/mv643xx_eth.c	2008-05-13 22:37:33.000000000 -0700
+++ linux-2.6.26-rc2-git3/drivers/net/mv643xx_eth.c	2008-05-13 23:15:37.000000000 -0700
@@ -1329,7 +1329,7 @@ static int mv643xx_eth_open(struct net_d
 	rdl(mp, INTERRUPT_CAUSE_EXTEND_REG(port_num));
 
 	err = request_irq(dev->irq, mv643xx_eth_int_handler,
-			IRQF_SHARED | IRQF_SAMPLE_RANDOM, dev->name, dev);
+			IRQF_SHARED, dev->name, dev);
 	if (err) {
 		printk(KERN_ERR "%s: Can not assign IRQ\n", dev->name);
 		return -EAGAIN;
diff -uprN linux-2.6.26-rc2-git3.orig/drivers/net/netxen/netxen_nic_main.c linux-2.6.26-rc2-git3/drivers/net/netxen/netxen_nic_main.c
--- linux-2.6.26-rc2-git3.orig/drivers/net/netxen/netxen_nic_main.c	2008-05-13 22:37:33.000000000 -0700
+++ linux-2.6.26-rc2-git3/drivers/net/netxen/netxen_nic_main.c	2008-05-13 23:15:49.000000000 -0700
@@ -838,7 +838,7 @@ static int netxen_nic_open(struct net_de
 	int err = 0;
 	int ctx, ring;
 	irq_handler_t handler;
-	unsigned long flags = IRQF_SAMPLE_RANDOM;
+	unsigned long flags = 0;
 
 	if (adapter->is_up != NETXEN_ADAPTER_UP_MAGIC) {
 		err = netxen_init_firmware(adapter);
diff -uprN linux-2.6.26-rc2-git3.orig/drivers/net/niu.c linux-2.6.26-rc2-git3/drivers/net/niu.c
--- linux-2.6.26-rc2-git3.orig/drivers/net/niu.c	2008-05-13 22:37:26.000000000 -0700
+++ linux-2.6.26-rc2-git3/drivers/net/niu.c	2008-05-13 23:19:55.000000000 -0700
@@ -5605,8 +5605,7 @@ static int niu_request_irq(struct niu *n
 		struct niu_ldg *lp = &np->ldg[i];
 
 		err = request_irq(lp->irq, niu_interrupt,
-				  IRQF_SHARED | IRQF_SAMPLE_RANDOM,
-				  np->dev->name, lp);
+				  IRQF_SHARED, np->dev->name, lp);
 		if (err)
 			goto out_free_irqs;
 
diff -uprN linux-2.6.26-rc2-git3.orig/drivers/net/qla3xxx.c linux-2.6.26-rc2-git3/drivers/net/qla3xxx.c
--- linux-2.6.26-rc2-git3.orig/drivers/net/qla3xxx.c	2008-05-13 22:38:09.000000000 -0700
+++ linux-2.6.26-rc2-git3/drivers/net/qla3xxx.c	2008-05-13 23:20:09.000000000 -0700
@@ -3618,7 +3618,7 @@ static int ql_adapter_up(struct ql3_adap
 {
 	struct net_device *ndev = qdev->ndev;
 	int err;
-	unsigned long irq_flags = IRQF_SAMPLE_RANDOM | IRQF_SHARED;
+	unsigned long irq_flags = IRQF_SHARED;
 	unsigned long hw_flags;
 
 	if (ql_alloc_mem_resources(qdev)) {
diff -uprN linux-2.6.26-rc2-git3.orig/drivers/net/tg3.c linux-2.6.26-rc2-git3/drivers/net/tg3.c
--- linux-2.6.26-rc2-git3.orig/drivers/net/tg3.c	2008-05-13 22:38:12.000000000 -0700
+++ linux-2.6.26-rc2-git3/drivers/net/tg3.c	2008-05-13 23:22:03.000000000 -0700
@@ -7496,12 +7496,12 @@ static int tg3_request_irq(struct tg3 *t
 		fn = tg3_msi;
 		if (tp->tg3_flags2 & TG3_FLG2_1SHOT_MSI)
 			fn = tg3_msi_1shot;
-		flags = IRQF_SAMPLE_RANDOM;
+		flags = 0;
 	} else {
 		fn = tg3_interrupt;
 		if (tp->tg3_flags & TG3_FLAG_TAGGED_STATUS)
 			fn = tg3_interrupt_tagged;
-		flags = IRQF_SHARED | IRQF_SAMPLE_RANDOM;
+		flags = IRQF_SHARED;
 	}
 	return (request_irq(tp->pdev->irq, fn, flags, dev->name, dev));
 }
@@ -7519,7 +7519,7 @@ static int tg3_test_interrupt(struct tg3
 	free_irq(tp->pdev->irq, dev);
 
 	err = request_irq(tp->pdev->irq, tg3_test_isr,
-			  IRQF_SHARED | IRQF_SAMPLE_RANDOM, dev->name, dev);
+			  IRQF_SHARED, dev->name, dev);
 	if (err)
 		return err;
 
diff -uprN linux-2.6.26-rc2-git3.orig/drivers/net/xen-netfront.c linux-2.6.26-rc2-git3/drivers/net/xen-netfront.c
--- linux-2.6.26-rc2-git3.orig/drivers/net/xen-netfront.c	2008-05-13 22:37:38.000000000 -0700
+++ linux-2.6.26-rc2-git3/drivers/net/xen-netfront.c	2008-05-13 23:20:47.000000000 -0700
@@ -1363,8 +1363,7 @@ static int setup_netfront(struct xenbus_
 		goto fail;
 
 	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
-					IRQF_SAMPLE_RANDOM, netdev->name,
-					netdev);
+					0, netdev->name, netdev);
 	if (err < 0)
 		goto fail;
 	netdev->irq = err;

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Alan Cox]

On Thu, 15 May 2008 00:11:10 -0700 (PDT)
Chris Peterson <cpeterso@cpeterso.com> wrote:

> 
> I know Jeff Garzik says he's not interested in an anti-entropy pogrom for existing net drivers, but here is the patch if anyone else is interested..? :)
> 
> Only 12 net drivers are affected, the last of the theoretically-exploitable network entropy.

Looks fine to me. If Jeff doesn't want to touch them then send them
direct to Andrew/Linus.

A more interesting alternative might be to mark things like network
drivers with a new flag say IRQF_SAMPLE_DUBIOUS so that users can be
given a switch to enable/disable their use depending upon the environment.

Alan

RE: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Brandeburg, Jesse]

Alan Cox wrote:
> Chris Peterson <cpeterso@cpeterso.com> wrote:
>> I know Jeff Garzik says he's not interested in an anti-entropy
>> pogrom for existing net drivers, but here is the patch if anyone
>> else is interested..? :)  
>> 
>> Only 12 net drivers are affected, the last of the
>> theoretically-exploitable network entropy. 
> 
> Looks fine to me. If Jeff doesn't want to touch them then send them
> direct to Andrew/Linus.
> 
> A more interesting alternative might be to mark things like network
> drivers with a new flag say IRQF_SAMPLE_DUBIOUS so that users can be
> given a switch to enable/disable their use depending upon the
> environment. 

we've been hearing rumblings of big customers wanting (maybe requiring)
wired network drivers from Intel to  advertise this flag.  Jeff have you
heard of such?

I think the argument is that a headless system (no keyboard/mouse, no
soundcard, probably no video) with a libata based driver and a network
driver without IRQF_SAMPLE_RANDOM has *no* sources of entropy.  In this
case the argument is very strong for at least *some* source of entropy
from interrupts so that randomness can get some external input.  Just
try rebuilding a kernel RPM over an ssh session and you'll see what I
mean.

In short, I agree with Alan's IRQF_SAMPLE_DUBIOUS, and know of Linux
customers who also want the same.

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Alan Cox]

> In short, I agree with Alan's IRQF_SAMPLE_DUBIOUS, and know of Linux
> customers who also want the same.

They should be made to read the Debian ssh security report - three times
and understand the same would apply to them if something did cause their
network packet arrivals to be observed or non-random

Far better would be to get your CPU guys to put an RNG back into the
systems or on the CPU die ala VIA. Given I've even seen people using VIA
boxes as a random number feeder (streaming random numbers over SSL) there
is clearly a demand 8)

Alan

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jeff Garzik]

Brandeburg, Jesse wrote:
> we've been hearing rumblings of big customers wanting (maybe requiring)
> wired network drivers from Intel to  advertise this flag.  Jeff have you
> heard of such?

I do indeed hear requests all the time, from people who want to make 
their boxes externally exploitable.  :)


> I think the argument is that a headless system (no keyboard/mouse, no
> soundcard, probably no video) with a libata based driver and a network
> driver without IRQF_SAMPLE_RANDOM has *no* sources of entropy.  In this
> case the argument is very strong for at least *some* source of entropy
> from interrupts so that randomness can get some external input.  Just
> try rebuilding a kernel RPM over an ssh session and you'll see what I
> mean.

There are entropy sources on a headless box, even one without audio and 
video, that are more secure than adding IRQF_SAMPLE_RANDOM to network 
drivers.

EGD demonstrates this, for example:  http://egd.sourceforge.net/  It 
looks at snmp, w, last, uptime, iostats, vmstats, etc.

And there are plenty of untapped entropy sources even so, such as 
reading temperature sensors, fan speed sensors on variable-speed fans, etc.

Heck, "smartctl -d ata -a /dev/FOO" produces output that could be hashed 
and added as entropy.

I'm interested to hear peoples' opinion of Chris P's patch, but 
definitely do not want to go in the other direction and start adding 
IRQF_SAMPLE_RANDOM, thus moving randomness in the direction of being 
externally exploitable.

	Jeff

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jeff Garzik]

Alan Cox wrote:
>> In short, I agree with Alan's IRQF_SAMPLE_DUBIOUS, and know of Linux
>> customers who also want the same.
> 
> They should be made to read the Debian ssh security report - three times
> and understand the same would apply to them if something did cause their
> network packet arrivals to be observed or non-random
> 
> Far better would be to get your CPU guys to put an RNG back into the
> systems or on the CPU die ala VIA. Given I've even seen people using VIA
> boxes as a random number feeder (streaming random numbers over SSL) there
> is clearly a demand 8)

The Treacherous Platform Module includes an RNG.

Someone (hi Jesse?) should implement support for TPM_GetRandom.

All the specs are public, and the hardware is already in users' hands.

	Jeff

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Rick Jones]

Is there nothing associated with the networking stack - NIC, driver, 
protocols, system calls which can be used as a source of entropy?

rick jones

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jeff Garzik]

Rick Jones wrote:
> Is there nothing associated with the networking stack - NIC, driver, 
> protocols, system calls which can be used as a source of entropy?

The issue is with being externally observable and controllable, or, with 
some irq mitigation schemes, be made /too regular/.

Interrupts (or timed mitigation events) may be triggered by the outside 
world, which makes it a very short path from remote attacker to local 
kernel entropy pool.

Finally, with severe load, there are little or no interrupts thanks to 
heavy mitigation, which means your entropy pool may be externally DoS'd.

Or at the very least, when your entropy needs to be INCREASED (due to 
heavy workload due to heavy traffic), your incoming entropy DECREASES 
due to decreased interrupts.

[I just realized that last one.  Heck, I'm even convincing myself even 
more its a bad idea]

	Jeff

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Kok, Auke]

Jeff Garzik wrote:
> Alan Cox wrote:
>>> In short, I agree with Alan's IRQF_SAMPLE_DUBIOUS, and know of Linux
>>> customers who also want the same.
>>
>> They should be made to read the Debian ssh security report - three times
>> and understand the same would apply to them if something did cause their
>> network packet arrivals to be observed or non-random
>>
>> Far better would be to get your CPU guys to put an RNG back into the
>> systems or on the CPU die ala VIA. Given I've even seen people using VIA
>> boxes as a random number feeder (streaming random numbers over SSL) there
>> is clearly a demand 8)
> 
> The Treacherous Platform Module includes an RNG.
> 
> Someone (hi Jesse?) should implement support for TPM_GetRandom.

Sounds like something he should neither use in the e1000 driver nor implement :)

This would be an interesting thing to the generic rng support in linux though

Auke

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Kok, Auke]

Jeff Garzik wrote:
> Rick Jones wrote:
>> Is there nothing associated with the networking stack - NIC, driver,
>> protocols, system calls which can be used as a source of entropy?
> 
> The issue is with being externally observable and controllable, or, with
> some irq mitigation schemes, be made /too regular/.
> 
> Interrupts (or timed mitigation events) may be triggered by the outside
> world, which makes it a very short path from remote attacker to local
> kernel entropy pool.
> 
> Finally, with severe load, there are little or no interrupts thanks to
> heavy mitigation, which means your entropy pool may be externally DoS'd.
> 
> Or at the very least, when your entropy needs to be INCREASED (due to
> heavy workload due to heavy traffic), your incoming entropy DECREASES
> due to decreased interrupts.
> 
> [I just realized that last one.  Heck, I'm even convincing myself even
> more its a bad idea]

so you have established that with any type of interrupt moderation (either NAPI or
some form of irq throttling in the NIC hardware) that IRQF_SA_RANDOM will become
more predictable.

How about the non-NAPI and non-throttled case? I would argue that without any irq
mitigation we can still use SA_RANDOM. Many (e.g. embedded) devices will want some
extra form of entropy, and providing them it in this form will be very beneficial
as these devices more commonly have no other form of entropy anymore.

Auke

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Rick Jones]

Jeff Garzik wrote:
> 
> 
> The Treacherous Platform Module includes an RNG.
> 
> Someone (hi Jesse?) should implement support for TPM_GetRandom.
> 
> All the specs are public, and the hardware is already in users' hands.

I will not pretend to understand everything mentioned, but having web 
searched on "TPM RNG" I came across this:

http://www.mail-archive.com/cryptography@metzdowd.com/msg06299.html

which may either encourage or discourage depending on one's point of view.

rick jones

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jeff Garzik]

Kok, Auke wrote:
> Jeff Garzik wrote:
>> Alan Cox wrote:
>>>> In short, I agree with Alan's IRQF_SAMPLE_DUBIOUS, and know of Linux
>>>> customers who also want the same.
>>> They should be made to read the Debian ssh security report - three times
>>> and understand the same would apply to them if something did cause their
>>> network packet arrivals to be observed or non-random
>>>
>>> Far better would be to get your CPU guys to put an RNG back into the
>>> systems or on the CPU die ala VIA. Given I've even seen people using VIA
>>> boxes as a random number feeder (streaming random numbers over SSL) there
>>> is clearly a demand 8)
>> The Treacherous Platform Module includes an RNG.
>>
>> Someone (hi Jesse?) should implement support for TPM_GetRandom.
> 
> Sounds like something he should neither use in the e1000 driver nor implement :)
> 
> This would be an interesting thing to the generic rng support in linux though

That's what I meant.  Support should be implemented in the appropriate 
place in order to solve the problem Jesse's complaining about.  That 
appropriate place being drivers/char/hw_random/

	Jeff

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jeff Garzik]

Rick Jones wrote:
> Jeff Garzik wrote:
>>
>>
>> The Treacherous Platform Module includes an RNG.
>>
>> Someone (hi Jesse?) should implement support for TPM_GetRandom.
>>
>> All the specs are public, and the hardware is already in users' hands.
> 
> I will not pretend to understand everything mentioned, but having web 
> searched on "TPM RNG" I came across this:
> 
> http://www.mail-archive.com/cryptography@metzdowd.com/msg06299.html
> 
> which may either encourage or discourage depending on one's point of view.

Yep, in theory you can do it in userspace right now, with zero kernel 
modifications.

But just my gut feeling about the Treacherous Platform Module makes me 
think we should have a kernel driver, for both ease of use, and ease of 
replacement should that usage turn out to be unwise.

	Jeff

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jeff Garzik]

Kok, Auke wrote:
> How about the non-NAPI and non-throttled case? I would argue that without any irq
> mitigation we can still use SA_RANDOM. Many (e.g. embedded) devices will want some

When was the last time we added a new driver for new hardware, and it 
didn't support NAPI and/or hw mitigation?  They are few and far between, 
and getting ever more rare.


> extra form of entropy, and providing them it in this form will be very beneficial
> as these devices more commonly have no other form of entropy anymore.

"no other form of entropy"?   See examples in this thread.

	Jeff

[PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

Jeff Garzik wrote:
> Someone (hi Jesse?) should implement support for TPM_GetRandom.

Here's an example patch (compile-tested only) to get people started.

This function calls the TPM command, and returns TPM header + RNG data 
in the supplied buffer.

A hw_random driver for TPM still needs to (a) parse the TPM header for 
return code, (b) extract RNG bytes out at offset 14, and (c) figure out 
some way to get a tpm_chip pointer.

Spec at 
https://www.trustedcomputinggroup.org/specs/TPM/TCPA_Main_TCG_Architecture_v1_1b.pdf 
describes TPM_GetRandom on page 215.

	Jeff



[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1606 bytes --]

diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
index a5d8bcb..4c3963b 100644
--- a/drivers/char/tpm/tpm.c
+++ b/drivers/char/tpm/tpm.c
@@ -579,6 +579,31 @@ void tpm_continue_selftest(struct tpm_chip *chip)
 }
 EXPORT_SYMBOL_GPL(tpm_continue_selftest);
 
+int tpm_getrandom(struct tpm_chip *chip, void *buf, size_t buflen)
+{
+	u8 rng_cmd[] = {
+		0, 193,			/* TPM_TAG_RQU_COMMAND */
+		0, 0, 0, 14,		/* length */
+		0, 0, 0, 70,		/* TPM_ORD_GetRandom */
+		0, 0, 0, 0,		/* number of bytes to return */
+	};
+	size_t tmp;
+
+	if (buflen <= sizeof(rng_cmd))
+		return -ENOSPC;
+
+	/* patch in requested/returned byte count.  TODO: more than 8-bit */
+	tmp = buflen - sizeof(rng_cmd);
+	if (tmp > 255)
+		tmp = 255;
+	rng_cmd[13] = tmp;
+
+	memcpy(buf, rng_cmd, sizeof(rng_cmd));
+
+	return tpm_transmit(chip, buf, buflen);
+}
+EXPORT_SYMBOL_GPL(tpm_getrandom);
+
 ssize_t tpm_show_enabled(struct device * dev, struct device_attribute * attr,
 			char *buf)
 {
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index e885148..bbab3c8 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -127,6 +127,7 @@ static inline void tpm_write_index(int base, int index, int value)
 extern void tpm_get_timeouts(struct tpm_chip *);
 extern void tpm_gen_interrupt(struct tpm_chip *);
 extern void tpm_continue_selftest(struct tpm_chip *);
+extern int tpm_getrandom(struct tpm_chip *, void *, size_t);
 extern unsigned long tpm_calc_ordinal_duration(struct tpm_chip *, u32);
 extern struct tpm_chip* tpm_register_hardware(struct device *,
 				 const struct tpm_vendor_specific *);

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Chris Peterson]

Please correct me if I'm wrong, but this thread's conclusions seem to be:

* network interrupts are an inappropriate source of entropy (see my patch)
* headless servers need entropy, but should seek a better solution,
such as EGD, hardware RNG, or other kernel entropy sources (but that
is a separate task)
* TPM RNG is a separate task and, if implemented, should be in
drivers/char/hw_random/


chris


On Thu, May 15, 2008 at 12:21 PM, Jeff Garzik <jeff@garzik.org> wrote:
> Kok, Auke wrote:
>>
>> How about the non-NAPI and non-throttled case? I would argue that without
>> any irq
>> mitigation we can still use SA_RANDOM. Many (e.g. embedded) devices will
>> want some
>
> When was the last time we added a new driver for new hardware, and it didn't
> support NAPI and/or hw mitigation?  They are few and far between, and
> getting ever more rare.
>
>
>> extra form of entropy, and providing them it in this form will be very
>> beneficial
>> as these devices more commonly have no other form of entropy anymore.
>
> "no other form of entropy"?   See examples in this thread.
>
>        Jeff
>
>
>

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jeff Garzik]

Chris Peterson wrote:
> Please correct me if I'm wrong, but this thread's conclusions seem to be:
> 
> * network interrupts are an inappropriate source of entropy (see my patch)
> * headless servers need entropy, but should seek a better solution,
> such as EGD, hardware RNG, or other kernel entropy sources (but that
> is a separate task)
> * TPM RNG is a separate task and, if implemented, should be in
> drivers/char/hw_random/

That's my own opinion, yes.  But not necessarily a consensus opinion :)

	Jeff

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Kok, Auke]

Jeff Garzik wrote:
> Chris Peterson wrote:
>> Please correct me if I'm wrong, but this thread's conclusions seem to be:
>>
>> * network interrupts are an inappropriate source of entropy (see my
>> patch)
>> * headless servers need entropy, but should seek a better solution,
>> such as EGD, hardware RNG, or other kernel entropy sources (but that
>> is a separate task)
>> * TPM RNG is a separate task and, if implemented, should be in
>> drivers/char/hw_random/
> 
> That's my own opinion, yes.  But not necessarily a consensus opinion :)

I agree it's by far the _best_ solution.

I think that some embedded devices that do not have any RNG hardware should be
able to turn off NAPI/irq mitigation and possibly fall back on IRQF_SA_RANDOM.
It's not as good as the above solution at all, but may be sufficient for headless
embedded devices that are dying for some entropy.

of course, with most of the network drivers being NAPI enabled by default this
pretty much is not realistic (as Jeff G. pointed out). Unless someone writes an
(e.g.) ethtool parameter to turn NAPI on/off :)

Auke

> 
>     Jeff
> 
> 

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Theodore Tso]

On Thu, May 15, 2008 at 01:01:36PM -0700, Chris Peterson wrote:
> Please correct me if I'm wrong, but this thread's conclusions seem to be:
> 
> * network interrupts are an inappropriate source of entropy (see my patch)
> * headless servers need entropy, but should seek a better solution,
> such as EGD, hardware RNG, or other kernel entropy sources (but that
> is a separate task)
> * TPM RNG is a separate task and, if implemented, should be in
> drivers/char/hw_random/

The TPM RNG task is probably best done in a user space process, which
might also do other things like pulling environmental noise from the
sound card's microphone, etc.

The problem is finding someone with the skills, time, and energy to
create the appropriate user space daemon.  All of the kernel
interfaces already exist; it's just matter of implementing the user
space support.

						- Ted

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Adrian Bunk]

On Thu, May 15, 2008 at 09:07:52AM -0700, Brandeburg, Jesse wrote:
> Alan Cox wrote:
> > Chris Peterson <cpeterso@cpeterso.com> wrote:
> >> I know Jeff Garzik says he's not interested in an anti-entropy
> >> pogrom for existing net drivers, but here is the patch if anyone
> >> else is interested..? :)  
> >> 
> >> Only 12 net drivers are affected, the last of the
> >> theoretically-exploitable network entropy. 
> > 
> > Looks fine to me. If Jeff doesn't want to touch them then send them
> > direct to Andrew/Linus.
> > 
> > A more interesting alternative might be to mark things like network
> > drivers with a new flag say IRQF_SAMPLE_DUBIOUS so that users can be
> > given a switch to enable/disable their use depending upon the
> > environment. 
> 
> we've been hearing rumblings of big customers wanting (maybe requiring)
> wired network drivers from Intel to  advertise this flag.  Jeff have you
> heard of such?
> 
> I think the argument is that a headless system (no keyboard/mouse, no
> soundcard, probably no video) with a libata based driver and a network
> driver without IRQF_SAMPLE_RANDOM has *no* sources of entropy.  In this
> case the argument is very strong for at least *some* source of entropy
> from interrupts so that randomness can get some external input.  Just
> try rebuilding a kernel RPM over an ssh session and you'll see what I
> mean.
> 
> In short, I agree with Alan's IRQF_SAMPLE_DUBIOUS, and know of Linux
> customers who also want the same.

We have two random number interfaces:
- /dev/random
- /dev/urandom

If a customer wants to get data from /dev/random although there's not 
enough entropy that's not a problem we can solve (we can only try to 
gather more real entropy if possible).

If he can live with dubious data he can simply use /dev/urandom .

If a customer wants to use /dev/random and demands to get dubious data 
there if nothing better is available fulfilling his wish only moves 
the security bug from his crappy application to the Linux kernel.

But what we could perhaps do with some kind of IRQF_SAMPLE_DUBIOUS would 
be to improve the quality of the data in /dev/urandom if there's not 
enough entropy available?

I have seen embedded systems with zero entropy, and dubious entropy 
might there be better than no entropy at all.
Or am I wrong on the latter?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jeff Garzik]

Theodore Tso wrote:
> On Thu, May 15, 2008 at 01:01:36PM -0700, Chris Peterson wrote:
>> Please correct me if I'm wrong, but this thread's conclusions seem to be:
>>
>> * network interrupts are an inappropriate source of entropy (see my patch)
>> * headless servers need entropy, but should seek a better solution,
>> such as EGD, hardware RNG, or other kernel entropy sources (but that
>> is a separate task)
>> * TPM RNG is a separate task and, if implemented, should be in
>> drivers/char/hw_random/
> 
> The TPM RNG task is probably best done in a user space process, which
> might also do other things like pulling environmental noise from the
> sound card's microphone, etc.
> 
> The problem is finding someone with the skills, time, and energy to
> create the appropriate user space daemon.  All of the kernel
> interfaces already exist; it's just matter of implementing the user
> space support.

rngd is already deployed in most distros, via rng-tools.  Motivated 
people are welcome to steal maintainership from me...

	Jeff

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jeff Garzik]

Adrian Bunk wrote:
> On Thu, May 15, 2008 at 09:07:52AM -0700, Brandeburg, Jesse wrote:
>> Alan Cox wrote:
>>> Chris Peterson <cpeterso@cpeterso.com> wrote:
>>>> I know Jeff Garzik says he's not interested in an anti-entropy
>>>> pogrom for existing net drivers, but here is the patch if anyone
>>>> else is interested..? :)  
>>>>
>>>> Only 12 net drivers are affected, the last of the
>>>> theoretically-exploitable network entropy. 
>>> Looks fine to me. If Jeff doesn't want to touch them then send them
>>> direct to Andrew/Linus.
>>>
>>> A more interesting alternative might be to mark things like network
>>> drivers with a new flag say IRQF_SAMPLE_DUBIOUS so that users can be
>>> given a switch to enable/disable their use depending upon the
>>> environment. 
>> we've been hearing rumblings of big customers wanting (maybe requiring)
>> wired network drivers from Intel to  advertise this flag.  Jeff have you
>> heard of such?
>>
>> I think the argument is that a headless system (no keyboard/mouse, no
>> soundcard, probably no video) with a libata based driver and a network
>> driver without IRQF_SAMPLE_RANDOM has *no* sources of entropy.  In this
>> case the argument is very strong for at least *some* source of entropy
>> from interrupts so that randomness can get some external input.  Just
>> try rebuilding a kernel RPM over an ssh session and you'll see what I
>> mean.
>>
>> In short, I agree with Alan's IRQF_SAMPLE_DUBIOUS, and know of Linux
>> customers who also want the same.
> 
> We have two random number interfaces:
> - /dev/random
> - /dev/urandom
> 
> If a customer wants to get data from /dev/random although there's not 
> enough entropy that's not a problem we can solve (we can only try to 
> gather more real entropy if possible).
> 
> If he can live with dubious data he can simply use /dev/urandom .
> 
> If a customer wants to use /dev/random and demands to get dubious data 
> there if nothing better is available fulfilling his wish only moves 
> the security bug from his crappy application to the Linux kernel.
> 
> But what we could perhaps do with some kind of IRQF_SAMPLE_DUBIOUS would 
> be to improve the quality of the data in /dev/urandom if there's not 
> enough entropy available?
> 
> I have seen embedded systems with zero entropy, and dubious entropy 
> might there be better than no entropy at all.
> Or am I wrong on the latter?

It's also relevant to the discussion to note that input data to kernel 
devrandom is mixed, and we can control the amount of "credit" applied to 
incoming entropy.

	Jeff

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jesper Juhl]

2008/5/15 Adrian Bunk <bunk@kernel.org>:
> On Thu, May 15, 2008 at 09:07:52AM -0700, Brandeburg, Jesse wrote:
>> Alan Cox wrote:
>> > Chris Peterson <cpeterso@cpeterso.com> wrote:
>> >> I know Jeff Garzik says he's not interested in an anti-entropy
>> >> pogrom for existing net drivers, but here is the patch if anyone
>> >> else is interested..? :)
>> >>
>> >> Only 12 net drivers are affected, the last of the
>> >> theoretically-exploitable network entropy.
>> >
>> > Looks fine to me. If Jeff doesn't want to touch them then send them
>> > direct to Andrew/Linus.
>> >
>> > A more interesting alternative might be to mark things like network
>> > drivers with a new flag say IRQF_SAMPLE_DUBIOUS so that users can be
>> > given a switch to enable/disable their use depending upon the
>> > environment.
>>
>> we've been hearing rumblings of big customers wanting (maybe requiring)
>> wired network drivers from Intel to  advertise this flag.  Jeff have you
>> heard of such?
>>
>> I think the argument is that a headless system (no keyboard/mouse, no
>> soundcard, probably no video) with a libata based driver and a network
>> driver without IRQF_SAMPLE_RANDOM has *no* sources of entropy.  In this
>> case the argument is very strong for at least *some* source of entropy
>> from interrupts so that randomness can get some external input.  Just
>> try rebuilding a kernel RPM over an ssh session and you'll see what I
>> mean.
>>
>> In short, I agree with Alan's IRQF_SAMPLE_DUBIOUS, and know of Linux
>> customers who also want the same.
>
> We have two random number interfaces:
> - /dev/random
> - /dev/urandom
>
> If a customer wants to get data from /dev/random although there's not
> enough entropy that's not a problem we can solve (we can only try to
> gather more real entropy if possible).
>
> If he can live with dubious data he can simply use /dev/urandom .
>
> If a customer wants to use /dev/random and demands to get dubious data
> there if nothing better is available fulfilling his wish only moves
> the security bug from his crappy application to the Linux kernel.
>
> But what we could perhaps do with some kind of IRQF_SAMPLE_DUBIOUS would
> be to improve the quality of the data in /dev/urandom if there's not
> enough entropy available?
>
> I have seen embedded systems with zero entropy, and dubious entropy
> might there be better than no entropy at all.
> Or am I wrong on the latter?
>

Note: I'm far from being any kind of expert on this topic, but I just
had a crazy idea.

What if we use the time between syscalls being made as a source of
(very little) entropy?

My point is that the rate (and timing between) syscalls is depending
on very many factors; the kernel version (and configuration), the
software installed, the software currently executing, the state of the
software currently executing, the number of apps executing, the amount
of network traffic, the accuracy of the hardware clock, the speed of
(various) IO sources (network, disk, USB, etc), the speed (and type)
of the CPU, the speed of memory. And various other things.
I'd guess that predicting the syscall rate and interval between
syscalls would be too hard to accurately predict to predict the actual
entropy generated by that sampling in any real world scenario.
Wouldn't that make it a reasonable entropy source for machines that
have no other sources (and a fair contributor of entropy even for
machines that do have other sources) ??


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Theodore Tso]

On Thu, May 15, 2008 at 06:04:04PM -0400, Jeff Garzik wrote:
>> I have seen embedded systems with zero entropy, and dubious entropy might 
>> there be better than no entropy at all.
>> Or am I wrong on the latter?
>
> It's also relevant to the discussion to note that input data to kernel 
> devrandom is mixed, and we can control the amount of "credit" applied to 
> incoming entropy.

Sure, and one possible thing to do is to simply always input the
interrupt information to the random number generator, but give it a
"entropy credit" of 0.  That has the net result of potentially
improving the entropy found in /dev/random and /dev/urandom, but not
necessarily compromising /dev/random, since /dev/random's output is
throttled by the entropy estimate.

The only cost of doing this would be the overhead in sending the
information into the entropy pool.

						- Ted

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Henrique de Moraes Holschuh]

On Thu, 15 May 2008, Jeff Garzik wrote:
> rngd is already deployed in most distros, via rng-tools.  Motivated  
> people are welcome to steal maintainership from me...

I was, once.  But I got into the trap of getting too out of sync from
upsteam rngd, and suddenly, packaging all those changes into incremental
patches become too much non-fun work for me to find the energy to do so.

It has been a few years since I really looked at that code, except for a
few minor Debian packaging fixes.  It is old code, and if my C is not
world-class now, it was even worse at that time.  But at least valgrind
tells me I fixed the worst bugs, and FIPS 140-2 (the old version of it
that still had criteria for non-deterministic RNGs) and DIEHARD couldn't
find any issues with its output after several runs on gigabyte-sized
files produced both from an Intel FWH RNG, and from a VIA PadLock RNG.

If anyone wants to poke at it, get the Debian rng-tools source package.
It directly supports the VIA PadLock in userspace in a suitably paranoid
mode (checks that the RNG was not reprogrammed at every read), and does
multithreading so that FIPS and output processing does not block (nor
gets blocked) by /dev/hw_random reading, etc.

Lots of cowebs on it, though.  And you probably need to get the version
in Debian unstable AND the version in Debian experimental, to get the
full code.  If someone really wants to work on it, I can send the VC
repo for them to play with.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Theodore Tso]

On Fri, May 16, 2008 at 12:13:39AM +0200, Jesper Juhl wrote:
> My point is that the rate (and timing between) syscalls is depending
> on very many factors; the kernel version (and configuration), the
> software installed, the software currently executing, the state of the
> software currently executing, the number of apps executing, the amount
> of network traffic, the accuracy of the hardware clock, the speed of
> (various) IO sources (network, disk, USB, etc), the speed (and type)
> of the CPU, the speed of memory. And various other things.

It Depends.

For certain workloads, a lot of these issues might just boil out, or
not result in as much entropy as you think.  Think about a certificate
server which doesn't get much traffic, but when it is contacted, it is
expected to create new high security RSA keys and the public key
certificates to go with it.  If the attacker knows the machine type,
distribution OS loaded, etc., it might not be that hard to brute force
guess many of the factors you have listed above.

Basically the question has always been one of the overhead to collect
and boil down any input data (which after all, any user space process
can send arbitrary data into the entropy pool via "cat my_secret_data
> /dev/random") which will never hurt and might help.  The tricky bit
is estimating how much "entropy" should be ascribed to data which is
sent into the entropy pool, and this is where you have to be very
careful.

If you screw the entropy credit information then security of
/dev/random will be impacted.  /dev/urandom won't be impacted since it
doesn't care about the entropy estimation.  That's why only root is
allowed to use the ioctl which atomically sends in some "known to be
random" data and the entropy credit ascribed to that data.

	     	     	     	    	     	- Ted

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jeff Garzik]

Brandeburg, Jesse wrote:
> we've been hearing rumblings of big customers wanting (maybe requiring)
> wired network drivers from Intel to  advertise this flag.  Jeff have you
> heard of such?
> 
> I think the argument is that a headless system (no keyboard/mouse, no
> soundcard, probably no video) with a libata based driver and a network
> driver without IRQF_SAMPLE_RANDOM has *no* sources of entropy.  In this
> case the argument is very strong for at least *some* source of entropy
> from interrupts so that randomness can get some external input.  Just
> try rebuilding a kernel RPM over an ssh session and you'll see what I
> mean.
> 
> In short, I agree with Alan's IRQF_SAMPLE_DUBIOUS, and know of Linux
> customers who also want the same.


So I guess a good message for customers might be:

Don't depend on an entropy source whose volume decreases as workload and 
network traffic increase.

	Jeff

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jeff Garzik]

Henrique de Moraes Holschuh wrote:
> If anyone wants to poke at it, get the Debian rng-tools source package.
> It directly supports the VIA PadLock in userspace in a suitably paranoid
> mode (checks that the RNG was not reprogrammed at every read), and does
> multithreading so that FIPS and output processing does not block (nor
> gets blocked) by /dev/hw_random reading, etc.


Neat.  I always did prefer VIA padlock in userspace.

I just sorta assumed a buffering, interrupt-driver TPM RNG driver would 
be better than doing it from userspace, but maybe that was a bad 
assumption to make on my part.  It should be quite doable to support TPM 
RNG entirely via userspace, at any rate.

	Jeff

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jesper Juhl]

2008/5/16 Theodore Tso <tytso@mit.edu>:
> On Fri, May 16, 2008 at 12:13:39AM +0200, Jesper Juhl wrote:
>> My point is that the rate (and timing between) syscalls is depending
>> on very many factors; the kernel version (and configuration), the
>> software installed, the software currently executing, the state of the
>> software currently executing, the number of apps executing, the amount
>> of network traffic, the accuracy of the hardware clock, the speed of
>> (various) IO sources (network, disk, USB, etc), the speed (and type)
>> of the CPU, the speed of memory. And various other things.
>
> It Depends.
>
> For certain workloads, a lot of these issues might just boil out, or
> not result in as much entropy as you think.  Think about a certificate
> server which doesn't get much traffic, but when it is contacted, it is
> expected to create new high security RSA keys and the public key
> certificates to go with it.  If the attacker knows the machine type,
> distribution OS loaded, etc., it might not be that hard to brute force
> guess many of the factors you have listed above.
>

Hmm, I would like to know how you'd do that.
Even if you a) know the exact distro installed (and the configuration,
b) know the exact hardware in the machine, c) know the exact time it
was booted and know that there have been no ssh logins or similar that
might have generated syscalls, d) know exactely how many requests (and
of what type) have been made to the server and the exact times they
were made.
How would you go about brute force guessing the contents of the entropy pool?

If the server does, for example, this; every second it samples the
number of syscalls made during that second and uses that number as the
base of adding one or two bits of entropy. Every time a syscall is
made it uses the "time since last syscall in 'us'" to add one bit of
entropy to the pool. I'd say that even if that server sees very little
(and even predictable) traffic, we may have; details of the filesystem
layout on disk, a timer interrupt happening a few microseconds early
due to a flaky chip, a background process initiating some action a
millisecond early/late for scheduling reasons, the switch the machine
is connected to causing a network packet to arrive a tiny bit later
than normal and various other factors like that, to cause the
generated entropy to be off by a bit or two compared to your guess -
and by the time you realize you are off, another spurrious event has
probably happened, so you'll never end up in-sync with the entropy
pool...  Or is there some "obvious entropy pool guessing method" that
I'm just not aware of???


> Basically the question has always been one of the overhead to collect
> and boil down any input data (which after all, any user space process
> can send arbitrary data into the entropy pool via "cat my_secret_data
>> /dev/random") which will never hurt and might help.  The tricky bit
> is estimating how much "entropy" should be ascribed to data which is
> sent into the entropy pool, and this is where you have to be very
> careful.
>
Yes, I'm aware of that, and I'm not suggesting to use syscall rates as
a generator of high amounts of high quality entropy. Im merely
suggesting that sampling syscall rates and time-between and using
those numbers as the source of very low amounts of low quality entropy
might be worth-while. It wouldn't hurt on machines that have other,
higher quality, entropy sources. On machines that have no other
entropy sources it would ensure that we always have a steady (although
slow) trickle of new entropy info available...

> If you screw the entropy credit information then security of
> /dev/random will be impacted.  /dev/urandom won't be impacted since it
> doesn't care about the entropy estimation.  That's why only root is
> allowed to use the ioctl which atomically sends in some "known to be
> random" data and the entropy credit ascribed to that data.
>
I'm only talking about providing some data for /dev/random here.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Henrique de Moraes Holschuh]

On Thu, 15 May 2008, Jeff Garzik wrote:
> Henrique de Moraes Holschuh wrote:
>> If anyone wants to poke at it, get the Debian rng-tools source package.
>> It directly supports the VIA PadLock in userspace in a suitably paranoid
>> mode (checks that the RNG was not reprogrammed at every read), and does
>> multithreading so that FIPS and output processing does not block (nor
>> gets blocked) by /dev/hw_random reading, etc.
>
> Neat.  I always did prefer VIA padlock in userspace.
>
> I just sorta assumed a buffering, interrupt-driver TPM RNG driver would  
> be better than doing it from userspace, but maybe that was a bad  
> assumption to make on my part.  It should be quite doable to support TPM  
> RNG entirely via userspace, at any rate.

I will tell you what.  If someone manages to get trousers to actually
*work* for data binding and sealing to the TPM in a ThinkPad T43 with an
NSC/Winbond TPM (their "sup3r s3kr1t TPM-inside-the-SuperIO 8394T" crap
one needs a NDA to get the documentation for), and I manage to duplicate
it (i.e. make it work here too), I will write the rng-tools trousers
interface code (at least for the Debian version) :-)

The kernel TPM driver works, the BIOS works, and I have the PCRs updated
properly during boot, but trousers get the tpm pubek key wrong for some
reason (the kernel driver can read it just fine).  The chip is good,
IBM's stuff worked just fine with it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Theodore Tso]

On Thu, May 15, 2008 at 06:44:22PM -0400, Jeff Garzik wrote:
>
> Neat.  I always did prefer VIA padlock in userspace.
>
> I just sorta assumed a buffering, interrupt-driver TPM RNG driver would be 
> better than doing it from userspace, but maybe that was a bad assumption to 
> make on my part.  It should be quite doable to support TPM RNG entirely via 
> userspace, at any rate.

If I recall correctly, you need access to a magic TPM key just to
*talk* to the TPM.  Normally that key is stored in a file, and of
course we can have a userspace helper pull that key into the kernel,
but given the extensive Trousers infrastructure that can do this
already, it seemed to make more sense to do it all in userspace, and
not require any more kernel code.

						- Ted

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Theodore Tso]

On Thu, May 15, 2008 at 08:02:21PM -0300, Henrique de Moraes Holschuh wrote:
> I will tell you what.  If someone manages to get trousers to actually
> *work* for data binding and sealing to the TPM in a ThinkPad T43 with an
> NSC/Winbond TPM (their "sup3r s3kr1t TPM-inside-the-SuperIO 8394T" crap
> one needs a NDA to get the documentation for), and I manage to duplicate
> it (i.e. make it work here too), I will write the rng-tools trousers
> interface code (at least for the Debian version) :-)
> 
> The kernel TPM driver works, the BIOS works, and I have the PCRs updated
> properly during boot, but trousers get the tpm pubek key wrong for some
> reason (the kernel driver can read it just fine).  The chip is good,
> IBM's stuff worked just fine with it.

There were some web pages on this subject that seemed imply that IBM
used a non-standard string-to-key algorithm, and that caused the
incompatibility with Trousers.  So if you initialized the TPM using
the IBM Windows drivers, you have to mess around with TSS to get it to
work correctly with Thinkpads.  I tried for a bit to try to get it to
work a while ago, but the few things I tried didn't work, and I
eventually lost interest.

							- Ted

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Henrique de Moraes Holschuh]

On Thu, 15 May 2008, Theodore Tso wrote:
> On Thu, May 15, 2008 at 08:02:21PM -0300, Henrique de Moraes Holschuh wrote:
> > I will tell you what.  If someone manages to get trousers to actually
> > *work* for data binding and sealing to the TPM in a ThinkPad T43 with an
> > NSC/Winbond TPM (their "sup3r s3kr1t TPM-inside-the-SuperIO 8394T" crap
> > one needs a NDA to get the documentation for), and I manage to duplicate
> > it (i.e. make it work here too), I will write the rng-tools trousers
> > interface code (at least for the Debian version) :-)
> > 
> > The kernel TPM driver works, the BIOS works, and I have the PCRs updated
> > properly during boot, but trousers get the tpm pubek key wrong for some
> > reason (the kernel driver can read it just fine).  The chip is good,
> > IBM's stuff worked just fine with it.
> 
> There were some web pages on this subject that seemed imply that IBM
> used a non-standard string-to-key algorithm, and that caused the

None of that, I cleared the TPM.  In fact, it took a while to find a
non-black-magic way to get the IBM BIOS to unhide the "Clear the TPM"
prompt...

Anyway, the TPM is clean, and I have tried with and without passphrases
(owner and operator), etc.  It is either a userspace to kernel
communications bug, or a trousers bug.  The PUBEK is there, the kernel
exports it nicely through sysfs, but trousers gets crap instead of the
PUBEK if I ask it to get the PUBEK (and therefore, nothing useful in
trousers works).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Henrique de Moraes Holschuh]

On Thu, 15 May 2008, Theodore Tso wrote:
> On Thu, May 15, 2008 at 06:44:22PM -0400, Jeff Garzik wrote:
> > I just sorta assumed a buffering, interrupt-driver TPM RNG driver would be 
> > better than doing it from userspace, but maybe that was a bad assumption to 
> > make on my part.  It should be quite doable to support TPM RNG entirely via 
> > userspace, at any rate.
> 
> If I recall correctly, you need access to a magic TPM key just to
> *talk* to the TPM.  Normally that key is stored in a file, and of

The TPM has some sort of idea of restricted operations.  It will depend
whether one can get random numbers as an anonymous party (and frankly, I
don't care for looking at the TCG docs right now to find out).

I certaily can ask the TPM "are you there?" even when it is disabled(!),
so I would not be too surprised to find out that, as long as it is
enabled, it will return random numbers to anyone.

But access to the TPM requires a control layer which must have excusive
access to the chip.  That layer would have to move into the kernel...
IMHO, it is just not worth even bothering with the idea, and just do it
all in userspace.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Andi Kleen]

Jeff Garzik <jeff@garzik.org> writes:
>
> A hw_random driver for TPM still needs to (a) parse the TPM header for
> return code, (b) extract RNG bytes out at offset 14, and (c) figure
> out some way to get a tpm_chip pointer.

(d) auto feed the information into random.c. Otherwise it'll be useless
for most people.

-Andi

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Alan Cox]

On Fri, 16 May 2008 02:27:36 +0200
Andi Kleen <andi@firstfloor.org> wrote:

> Jeff Garzik <jeff@garzik.org> writes:
> >
> > A hw_random driver for TPM still needs to (a) parse the TPM header for
> > return code, (b) extract RNG bytes out at offset 14, and (c) figure
> > out some way to get a tpm_chip pointer.
> 
> (d) auto feed the information into random.c. Otherwise it'll be useless
> for most people.

No - you don't want to do FIPS randomness verification in kernel space.
Plus all the other random generator inputs are done via the user space
daemon as they should be.

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Andi Kleen]

Alan Cox wrote:
> On Fri, 16 May 2008 02:27:36 +0200
> Andi Kleen <andi@firstfloor.org> wrote:
> 
>> Jeff Garzik <jeff@garzik.org> writes:
>>> A hw_random driver for TPM still needs to (a) parse the TPM header for
>>> return code, (b) extract RNG bytes out at offset 14, and (c) figure
>>> out some way to get a tpm_chip pointer.
>> (d) auto feed the information into random.c. Otherwise it'll be useless
>> for most people.
> 
> No - you don't want to do FIPS randomness verification in kernel space.

Just think a little bit: system has no randomness source except the
hardware RNG. you do your strange randomness verification. if it fails
what do you do? You don't feed anything into your entropy pool and all
your  random output is predictable (just boot time)  If you add anything
predictable from another source it's still predictable, no difference.

Also in general what happens in the hypothetical
case that your random generator e.g. generates all zeros (which
is very unlikely but let's assume it): your entropy doesn't get
significantly worse than it was before. Previously it was just
seeded with the boot time (or other sources) and now you're adding some
zeroes. The output is still as random as the previous state.
While that changes the state of the entropy pool it doesn't make it any
easier to predict.

The only problem you got from possible bogus input is that the entropy
counts will be wrong, but in my experience nearly all programs
use /dev/urandom anyways because /dev/random is just a DoS waiting
to happen and user space programmers know that.

Basically with this insisting on FIPS you're violating the
strong variant of Steinbach's rule: not only "never test for an
error condition you don't know how to handle", but
"never test for an error condition you can't handle"

Also why do you not trust your random generator but trust
your CPU to correctly execute the cryptographic algorithm?
Not trusting your own hardware doesn't really make any sense here.

> Plus all the other random generator inputs are done via the user space
> daemon as they should be.

Yes and which makes them about useless because distros don't run that
daemon by default so users don't get the feature. Besides it's all not
needed anyways because the FIPS verification is pointless.

-Andi

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Herbert Xu]

On Fri, May 16, 2008 at 12:19:49PM +0200, Andi Kleen wrote:
>
> Just think a little bit: system has no randomness source except the
> hardware RNG. you do your strange randomness verification. if it fails
> what do you do? You don't feed anything into your entropy pool and all
> your  random output is predictable (just boot time)  If you add anything
> predictable from another source it's still predictable, no difference.

You can continue to feed data into the pool even if it fails the
test.  You just keep the entropy value same as before.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Adrian Bunk]

On Fri, May 16, 2008 at 12:19:49PM +0200, Andi Kleen wrote:
>...
> The only problem you got from possible bogus input is that the entropy
> counts will be wrong, but in my experience nearly all programs
> use /dev/urandom anyways because /dev/random is just a DoS waiting
> to happen and user space programmers know that.
>...

If programs just need some random data without relying on the fact that 
it's cryptographically strong /dev/urandom is the right choice.

But some programs need entropy for doing crypto stuff, and a local DoS 
is harmless compared to the consequences of bad /dev/random data.

Consider as a worst case the just discovered OpenSSL bug in Debian where 
all accounts with public key authentification and keys created on a 
Debian/Ubuntu system during the last 20 months [1] can be taken over by 
an attacker within less than 20 minutes with a simple brute force 
attack. [2]

> -Andi

cu
Adrian

[1] 13 months for Debian stable users
[2] http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2008-05/msg00416.html

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Lennart Sorensen]

On Thu, May 15, 2008 at 03:21:49PM -0400, Jeff Garzik wrote:
> "no other form of entropy"?   See examples in this thread.

So where does one get entropy if not the ethernet adapter on many
embedded systems?  If you have no mouse, no keyboard, no hardware number
generator, just ethernet ports and a serial console that usually
receives no input.  While ethernet might not be preferable if you have
something else, sometimes you really don't have anything else.

-- 
Len Sorensen

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jeff Garzik]

Lennart Sorensen wrote:
> On Thu, May 15, 2008 at 03:21:49PM -0400, Jeff Garzik wrote:
>> "no other form of entropy"?   See examples in this thread.
> 
> So where does one get entropy if not the ethernet adapter on many
> embedded systems?  If you have no mouse, no keyboard, no hardware number
> generator, just ethernet ports and a serial console that usually
> receives no input.  While ethernet might not be preferable if you have
> something else, sometimes you really don't have anything else.

Already answered in this thread...  EGD illustrates how many sources of 
entropy remain, even in the example you just gave.

Further, you do not want to rely on entropy from a source that declines 
just as network traffic increases.

	Jeff

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Will Newton]

On Fri, May 16, 2008 at 2:40 PM, Jeff Garzik <jeff@garzik.org> wrote:
> Lennart Sorensen wrote:
>>
>> On Thu, May 15, 2008 at 03:21:49PM -0400, Jeff Garzik wrote:
>>>
>>> "no other form of entropy"?   See examples in this thread.
>>
>> So where does one get entropy if not the ethernet adapter on many
>> embedded systems?  If you have no mouse, no keyboard, no hardware number
>> generator, just ethernet ports and a serial console that usually
>> receives no input.  While ethernet might not be preferable if you have
>> something else, sometimes you really don't have anything else.
>
> Already answered in this thread...  EGD illustrates how many sources of
> entropy remain, even in the example you just gave.
>
> Further, you do not want to rely on entropy from a source that declines just
> as network traffic increases.

I don't know egd that well, but from a cursory look it gets data from
such things as w or last (wtmp) which is static on most embedded
boxes. It also uses netstat and snmp - surely this is at least as easy
to manipulate as interrupt timings? I'm not a cryptographer by any
means but it looks as if it works by magic. Last changed 2002, written
in perl. No, I don't think I'll be shipping this on any systems any
time soon.

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Lennart Sorensen]

On Fri, May 16, 2008 at 02:59:03PM +0100, Will Newton wrote:
> I don't know egd that well, but from a cursory look it gets data from
> such things as w or last (wtmp) which is static on most embedded
> boxes. It also uses netstat and snmp - surely this is at least as easy
> to manipulate as interrupt timings? I'm not a cryptographer by any
> means but it looks as if it works by magic. Last changed 2002, written
> in perl. No, I don't think I'll be shipping this on any systems any
> time soon.

I will certainly keep applying a patch to the kernel to enable the
ethernet driver as a source of entropy.  I won't expect the upstream
kernel to want it, but it certainly is useful to have some source of
entropy.  Generating an ssl key or the like can take an awful long time
if you have no sources at all.

The last thing I need is another perl script eating up resources for no
good reason.

-- 
Len Sorensen

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Jeff Garzik]

Will Newton wrote:
> On Fri, May 16, 2008 at 2:40 PM, Jeff Garzik <jeff@garzik.org> wrote:
>> Lennart Sorensen wrote:
>>> On Thu, May 15, 2008 at 03:21:49PM -0400, Jeff Garzik wrote:
>>>> "no other form of entropy"?   See examples in this thread.
>>> So where does one get entropy if not the ethernet adapter on many
>>> embedded systems?  If you have no mouse, no keyboard, no hardware number
>>> generator, just ethernet ports and a serial console that usually
>>> receives no input.  While ethernet might not be preferable if you have
>>> something else, sometimes you really don't have anything else.
>> Already answered in this thread...  EGD illustrates how many sources of
>> entropy remain, even in the example you just gave.
>>
>> Further, you do not want to rely on entropy from a source that declines just
>> as network traffic increases.
> 
> I don't know egd that well, but from a cursory look it gets data from
> such things as w or last (wtmp) which is static on most embedded
> boxes.

Inevitably some of the local-machine entropy sources will be static or 
externally influenced.  That's the whole point of using several.  If 
using one source was sufficient... we would just use that one and be 
done with it.  :)

The questions to ask are

* is this collective snapshot of local machine state sufficiently unique?

* is this local-machine state externally controllable within realistic 
orders of complexity?


> It also uses netstat and snmp - surely this is at least as easy
> to manipulate as interrupt timings?

netstat reflects local machine state of all sockets, including local 
ones, and including local details like tcp in-q and out-q.  snmp can 
query MIBs such as ethernet wire stats, gaining entropy from 
pause/collision/etc. frame statistics.

A set of mitigated network interrupt events is far, far more predictable 
and controllable than the collective state of a machine's network 
sockets, or the electrical state of the ethernet LAN link.

For network-interrupt randomness to be subverted in some cases, one 
might need only to increase overall network traffic to a certain level.

	Jeff

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Alan Cox]

> receives no input.  While ethernet might not be preferable if you have
> something else, sometimes you really don't have anything else.

Ethernet is observable so ethernet isn't entropy. There is no "anything
else" here -> there is no *anything*

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Andi Kleen]

Adrian Bunk wrote:
> On Fri, May 16, 2008 at 12:19:49PM +0200, Andi Kleen wrote:
>> ...
>> The only problem you got from possible bogus input is that the entropy
>> counts will be wrong, but in my experience nearly all programs
>> use /dev/urandom anyways because /dev/random is just a DoS waiting
>> to happen and user space programmers know that.
>> ...
> 
> If programs just need some random data without relying on the fact that 
> it's cryptographically strong /dev/urandom is the right choice.

No in this case /dev/urandom is the wrong choice. You should seed
then some standard RND with the time,pid as is the classical way
and not use any precious entropy. Yes some programs don't do that,
but they're wrong and actually slightly dangerous.

> But some programs need entropy for doing crypto stuff, and a local DoS 
> is harmless compared to the consequences of bad /dev/random data.

Even the cryptographic programs normally use /dev/urandom to get
session keys etc. That is because they are definitely concerned about
local DoS. Just strace your ssh daemon or your SSL web server to see
what I mean.

> Consider as a worst case the just discovered OpenSSL bug in Debian where 
> all accounts with public key authentification and keys created on a 
> Debian/Ubuntu system during the last 20 months [1] can be taken over by 
> an attacker within less than 20 minutes with a simple brute force 
> attack. [2]

Yes, but if you read the context of that patch it commented out
the code that accessed /dev/urandom!

Please reread my analysis of the issue. If you have already entropy in
the pool  the additional feed doesn't change anything. And if you don't
it still stays the same.

-Andi

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Andi Kleen]

Herbert Xu wrote:
> On Fri, May 16, 2008 at 12:19:49PM +0200, Andi Kleen wrote:
>> Just think a little bit: system has no randomness source except the
>> hardware RNG. you do your strange randomness verification. if it fails
>> what do you do? You don't feed anything into your entropy pool and all
>> your  random output is predictable (just boot time)  If you add anything
>> predictable from another source it's still predictable, no difference.
> 
> You can continue to feed data into the pool even if it fails the
> test.  You just keep the entropy value same as before.

You could do that, but what advantage would it have? I don't think it's
worth running the FIPS test, or rather requiring the user land daemon
and leaving behind most of the userbase just for this.

-Andi

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Lennart Sorensen]

On Fri, May 16, 2008 at 04:10:29PM +0100, Alan Cox wrote:
> Ethernet is observable so ethernet isn't entropy. There is no "anything
> else" here -> there is no *anything*

So what is one to do if a few applications want to read from /dev/random
but you have no excellent source of entropy on the system?  Wait
forever?  I think ethernet interrupts are better than nothing, and I
really doubt that someone would be able to predict what the entropy
generated would be in practice.  If you have that good access to the
physical network, then probably have physical access to the system
itself, in which case it is all irrelevant.

-- 
Len Sorensen

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Alan Cox]

> So what is one to do if a few applications want to read from /dev/random
> but you have no excellent source of entropy on the system?  Wait
> forever?  

Yes.

If they don't need that level of security they can use /dev/urandom.
Piping network randomness into /dev/urandom is probably quite sensible
but not into /dev/random.

Alan

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Kok, Auke]

Alan Cox wrote:
>> So what is one to do if a few applications want to read from /dev/random
>> but you have no excellent source of entropy on the system?  Wait
>> forever?  
> 
> Yes.
> 
> If they don't need that level of security they can use /dev/urandom.
> Piping network randomness into /dev/urandom is probably quite sensible
> but not into /dev/random.

I remember Jesse telling that he had this very same experience while installing a
RH box on a headless system with a serial console - a box prompted the user to
rattle a keyboard in order for the ssh key generation to continue :)

you absolutely don't want to use urandom for that I assume, but if the system just
sits dead waiting for randomness, and you can't see the popup asking for some
entropy, you're pretty much screwed :)

Auke

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Lennart Sorensen]

On Fri, May 16, 2008 at 07:11:25PM +0100, Alan Cox wrote:
> If they don't need that level of security they can use /dev/urandom.
> Piping network randomness into /dev/urandom is probably quite sensible
> but not into /dev/random.

Well it isn't that things liks ssh and ssl and such don't need that
level of security, but if there is no way to get it you have to go for
the best you can get.  Fortunately it seems hardware RNG is becoming
more common on embedded CPUs.

-- 
Len Sorensen

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Lennart Sorensen]

On Fri, May 16, 2008 at 02:41:38PM -0400, Lennart Sorensen wrote:
> Well it isn't that things liks ssh and ssl and such don't need that
> level of security, but if there is no way to get it you have to go for
> the best you can get.  Fortunately it seems hardware RNG is becoming
> more common on embedded CPUs.

Of course in some cases, someone might be typing stuff at the serial
console and you get some actual random input, but you can't rely on it
being there, its nice to get it if its there though.

-- 
Len Sorensen

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[David Miller]

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Fri, 16 May 2008 10:56:35 +0100

> On Fri, 16 May 2008 02:27:36 +0200
> Andi Kleen <andi@firstfloor.org> wrote:
> 
> > Jeff Garzik <jeff@garzik.org> writes:
> > >
> > > A hw_random driver for TPM still needs to (a) parse the TPM header for
> > > return code, (b) extract RNG bytes out at offset 14, and (c) figure
> > > out some way to get a tpm_chip pointer.
> > 
> > (d) auto feed the information into random.c. Otherwise it'll be useless
> > for most people.
> 
> No - you don't want to do FIPS randomness verification in kernel space.
> Plus all the other random generator inputs are done via the user space
> daemon as they should be.

This does remind me of a deficiency in the current hwrng driver layer
that I noticed while working on the Niagara2 RNG driver.

If the device allows tweaking of settings (selecting different voltage
oscillators per entropy source in my case) we really need some way to
test the randomness generated by different setting so that we can make
an optimal choice.

One common scheme is to compute the Renyi entropy for blocks of random
data using the various settings, something else we don't want in the
kernel.

So we would need some kind of interface so that userland could handle
something like that.  Something like:

1) Export number of possible configurations to userspace
2) Allow userspace to simply iterate over the configurations,
   something as simple as just specifying an integer index
   in the range 0 to num_configs

Then userspace can do randomness analysis of the different configurations
however it and the user's choosen policy dictate.

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Alan Cox]

> > Piping network randomness into /dev/urandom is probably quite sensible
> > but not into /dev/random.
> 
> Well it isn't that things liks ssh and ssl and such don't need that
> level of security, but if there is no way to get it you have to go for
> the best you can get.

So open /dev/urandom in that case. It's a user space problem - this is
policy.

Alan

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Gilles Espinasse]

----- Original Message ----- 
From: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
To: "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>
Cc: "Jeff Garzik" <jeff@garzik.org>; "Kok, Auke" <auke-jan.h.kok@intel.com>;
"Rick Jones" <rick.jones2@hp.com>; "Brandeburg, Jesse"
<jesse.brandeburg@intel.com>; "Chris Peterson" <cpeterso@cpeterso.com>;
<netdev@vger.kernel.org>; <linux-kernel@vger.kernel.org>
Sent: Friday, May 16, 2008 5:10 PM
Subject: Re: [PATCH] drivers/net: remove network drivers' last few uses of
IRQF_SAMPLE_RANDOM


> > receives no input.  While ethernet might not be preferable if you have
> > something else, sometimes you really don't have anything else.
>
> Ethernet is observable so ethernet isn't entropy. There is no "anything
> else" here -> there is no *anything*
> --
That's funny
It does look to disturb some kernel developper that ethernet may be sniffed
to feed a RNG
even that could be very hard to reach any effective result in the case of a
machine splitting
different network segments.

In the same time, it does not disturb openssl developpers to include non
initialised
memory that may or may not be predictable to feed a RNG.
http://marc.info/?l=openssl-dev&m=121095151003011&w=2

 Gilles

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Benny Amorsen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> If they don't need that level of security they can use /dev/urandom.
> Piping network randomness into /dev/urandom is probably quite sensible
> but not into /dev/random.

Perhaps it would be possible to make most types of interrupts add
entropy, but not credit any entropy?


/Benny

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Lennart Sorensen]

On Fri, May 16, 2008 at 09:04:45PM +0100, Alan Cox wrote:
> So open /dev/urandom in that case. It's a user space problem - this is
> policy.

How does user space know?  Maybe someone is using the serial console,
maybe not.

-- 
Len Sorensen

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Alan Cox]

On Fri, 16 May 2008 16:39:33 -0400
lsorense@csclub.uwaterloo.ca (Lennart Sorensen) wrote:

> On Fri, May 16, 2008 at 09:04:45PM +0100, Alan Cox wrote:
> > So open /dev/urandom in that case. It's a user space problem - this is
> > policy.
> 
> How does user space know?  Maybe someone is using the serial console,
> maybe not.

How does the kernel know - it has even less useful policy information ?

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Rick Jones]

Jeff Garzik wrote:
> The Treacherous Platform Module includes an RNG.
> 
> Someone (hi Jesse?) should implement support for TPM_GetRandom.
> 
> All the specs are public, and the hardware is already in users' hands.

My curiousity got the better of me, so I enabled the TPM (Infineon)

moe:~# dmesg | grep -i tpm
tpm_inf_pnp 00:05: Found TPM with ID IFX0101
tpm_inf_pnp 00:05: TPM found: config base 0xff5b804e, data base 
0xff5b8000, chip version 0x0006, vendor id 0x15d1 (Infineon), product id 
0x0006 (SLD 9630 TT 1.1)

on a system I had, and using whatever Debian Lenny (w 2.6.24-1 kernel) 
offers for trousers and tcsd etc, a bunch of help from some other HPers, 
and a hacked example program from an HP-UX document I pressed-on without 
much understanding and arrived at:

moe:~# time ./raj_example -c 1000
making 1000 Tspi_TPM_GetRandom calls of 16 bytes each

real    0m28.033s
user    0m0.000s
sys     0m0.000s


28.0033s / 1000 calls = 2.8 ms per call.  While this was happening top 
was reporting  1% CPU time in the tcsd.

I've no idea how much feeding /dev/random would want and how often, but 
there is some crude data on overhead for pulling random numbers out of 
at least one TPM.  Here is some varying of the number of bytes requested 
each time:

moe:~# for i in 1 16 32 64
 > do
 > time ./raj_example -c 1000 -r $i
 > done
making 1000 Tspi_TPM_GetRandom calls of 1 bytes each

real    0m24.146s
user    0m0.008s
sys     0m0.000s
making 1000 Tspi_TPM_GetRandom calls of 16 bytes each

real    0m28.032s
user    0m0.000s
sys     0m0.000s
making 1000 Tspi_TPM_GetRandom calls of 32 bytes each

real    0m28.032s
user    0m0.004s
sys     0m0.000s
making 1000 Tspi_TPM_GetRandom calls of 64 bytes each

real    0m36.032s
user    0m0.004s
sys     0m0.000s

rick jones
no, i don't plan on adding this to netperf :)

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Herbert Xu]

On Fri, May 16, 2008 at 06:25:12PM +0200, Andi Kleen wrote:
>
> You could do that, but what advantage would it have? I don't think it's
> worth running the FIPS test, or rather requiring the user land daemon
> and leaving behind most of the userbase just for this.

The obvious advantage is that you don't unblock /dev/random readers
until there is real entropy available.

Remember that a hardware RNG failure is a catastrophic event, so
a heavy-handed response such as blocking /dev/random is reasonable.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Chris Peterson]

> If they don't need that level of security they can use /dev/urandom.
> Piping network randomness into /dev/urandom is probably quite sensible
> but not into /dev/random.

If there was an IRQF_SAMPLE_DUBIOUS or IRQF_SAMPLE_URANDOM for network
device IRQs to feed /dev/urandom, are there any other IRQs that should
use it instead of IRQF_SAMPLE_RANDOM?

>From a cursory search, it seems like:

* network drivers could use IRQF_SAMPLE_URANDOM
* all (?) other device drivers could use IRQF_SAMPLE_RANDOM
* and timer IRQs should not use either?


chris

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Andi Kleen]

Herbert Xu wrote:
> On Fri, May 16, 2008 at 06:25:12PM +0200, Andi Kleen wrote:
>> You could do that, but what advantage would it have? I don't think it's
>> worth running the FIPS test, or rather requiring the user land daemon
>> and leaving behind most of the userbase just for this.
> 
> The obvious advantage is that you don't unblock /dev/random readers
> until there is real entropy available.

As far as I can figure out with some research (stracing, strings) pretty
much every interesting cryptographic software except gpg keygen uses
/dev/urandom anyways. They have to because too many systems don't have
enough entropy and /dev/random simply blocks far too often and does not
really work. When you check the now famous openssl source you see it
uses /dev/urandom first simply because of this problem.  They only
have /dev/random for systems where /dev/urandom is not available.

That is because the real world cryptographers care as much about DoS as
about other issues.

It's also quite understandable:
"Sorry our company couldn't receive email because nobody banged on the
keyboard of the mail server"
Clearly that would be absurd, but if e.g. openssl used /dev/random you
would easily get into that situation.

Part of the problem here is of course this strange insistence to not
auto-feed from all available random sources. If you set this entropy
standards too high soon none are left and the entropy pool
is often only very poorly fed. So by setting too high
standards you actually lower practical security.

> Remember that a hardware RNG failure is a catastrophic event, 

Is it? The pool is just as random as it was before because the hash
output will depend on all previous input.  So even if you e.g. add a
known string of zeroes for example it should be still as much or as
little unpredictible as it was before. The big difference is
that it is just cryptographic security instead of true entropy,
but without enough entropy (or you not trusting your entropy) there's no
choice.

Also my assumption is that if the hardware RNG fails the rest of
the system (CPU, memory) will likely fail with it. Well I admit
I'm not 100% sure about that, but the stories going around about
RNG failures are so vaguely folksy that my assumptions are likely
as good as anybody elses :)

> so a heavy-handed response such as blocking /dev/random is reasonable.

I only know of GPG initial key gen who really relies on it and I'm sure
I wasn't the only one to feel silly when  banging random keys on the
keyboard while generating a key :)

Obviously that doesn't work for all the interesting cases like
session keys etc, or even ssh keygen so they don't use it for that. It's
pretty much unusable for all "invisible cryptography" where the user is
not (or only very vaguely) aware there is cryptography being used and
that is the far majority of cryptography. gpg can only get away with it
because they assume an educated user and even there it doesn't work
well.

I've been actually pondering a kind of compromise here:

Would people be ok with kernel auto-feeding for /dev/urandom only? I've
been pondering that and I think that would work just as well in practice
 given the facts above. Then you would still only get blocking
/dev/random with the user daemon, but that won't matter because all
the usual users don't rely on thatanyways.

The only open question is if the pools need to be duplicated or not for
this case.

-Andi

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Chris Peterson]

> Would people be ok with kernel auto-feeding for /dev/urandom only? I've
> been pondering that and I think that would work just as well in practice
>  given the facts above. Then you would still only get blocking
> /dev/random with the user daemon, but that won't matter because all
> the usual users don't rely on thatanyways.

Andi, can you please clarify what you mean by "auto-feeding
/dev/urandom only" and "only get blocking /dev/random with the user
daemon"? Are you suggesting that the kernel provides /dev/urandom and
a userspace daemon (e.g. EGD) provides /dev/random?

Also, if crypto apps like ssh and openssl use on "insecure"
/dev/urandom, then who actually relies on /dev/random? For comparison,
FreeBSD does not even (AFAIK) have /dev/urandom. FreeBSD's /dev/random
is nonblocking (like Linux's /dev/urandom) and includes network
entropy.


chris

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Arjan van de Ven]

On Sat, 17 May 2008 12:54:02 -0700
"Chris Peterson" <cpeterso@cpeterso.com> wrote:

> Andi, can you please clarify what you mean by "auto-feeding
> /dev/urandom only" and "only get blocking /dev/random with the user
> daemon"? Are you suggesting that the kernel provides /dev/urandom and
> a userspace daemon (e.g. EGD) provides /dev/random?
> 
> Also, if crypto apps like ssh and openssl use on "insecure"
> /dev/urandom, then who actually relies on /dev/random?

gpg does for key generation

> For comparison,
> FreeBSD does not even (AFAIK) have /dev/urandom. FreeBSD's /dev/random
> is nonblocking (like Linux's /dev/urandom) and includes network
> entropy.
> 

I think the big kicker is the difference between a session key (short
lived) and a "real" key such as a gpg key that lives for a long time
and is used for multile sessions and with different users (in crypto
speak, Alice uses the same random key for Bob, Charlotte and David and
potentially for a long time). For a session key, urandom is very likely
an acceptable compromise; there's only so much data it's used for.
For long term keys I can totally see why /dev/random is used instead.

So both have value, just in different circumstances.

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Adrian Bunk]

On Fri, May 16, 2008 at 10:08:29PM +0200, Gilles Espinasse wrote:
> 
> That's funny
> It does look to disturb some kernel developper that ethernet may be sniffed
> to feed a RNG
> even that could be very hard to reach any effective result in the case of a
> machine splitting
> different network segments.
> 
> In the same time, it does not disturb openssl developpers to include non
> initialised
> memory that may or may not be predictable to feed a RNG.
> http://marc.info/?l=openssl-dev&m=121095151003011&w=2

Why should it disturb them?

As is explained in the email you quote it cannot make the RNG
output worse.

>  Gilles

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Matt Mackall]

On Fri, 2008-05-16 at 00:55 +0300, Adrian Bunk wrote:
> On Thu, May 15, 2008 at 09:07:52AM -0700, Brandeburg, Jesse wrote:
> > Alan Cox wrote:
> > > Chris Peterson <cpeterso@cpeterso.com> wrote:
> > >> I know Jeff Garzik says he's not interested in an anti-entropy
> > >> pogrom for existing net drivers, but here is the patch if anyone
> > >> else is interested..? :)  
> > >> 
> > >> Only 12 net drivers are affected, the last of the
> > >> theoretically-exploitable network entropy. 
> > > 
> > > Looks fine to me. If Jeff doesn't want to touch them then send them
> > > direct to Andrew/Linus.
> > > 
> > > A more interesting alternative might be to mark things like network
> > > drivers with a new flag say IRQF_SAMPLE_DUBIOUS so that users can be
> > > given a switch to enable/disable their use depending upon the
> > > environment. 
> > 
> > we've been hearing rumblings of big customers wanting (maybe requiring)
> > wired network drivers from Intel to  advertise this flag.  Jeff have you
> > heard of such?
> > 
> > I think the argument is that a headless system (no keyboard/mouse, no
> > soundcard, probably no video) with a libata based driver and a network
> > driver without IRQF_SAMPLE_RANDOM has *no* sources of entropy.  In this
> > case the argument is very strong for at least *some* source of entropy
> > from interrupts so that randomness can get some external input.  Just
> > try rebuilding a kernel RPM over an ssh session and you'll see what I
> > mean.
> > 
> > In short, I agree with Alan's IRQF_SAMPLE_DUBIOUS, and know of Linux
> > customers who also want the same.
> 
> We have two random number interfaces:
> - /dev/random
> - /dev/urandom
> 
> If a customer wants to get data from /dev/random although there's not 
> enough entropy that's not a problem we can solve (we can only try to 
> gather more real entropy if possible).
> 
> If he can live with dubious data he can simply use /dev/urandom .
> 
> If a customer wants to use /dev/random and demands to get dubious data 
> there if nothing better is available fulfilling his wish only moves 
> the security bug from his crappy application to the Linux kernel.
> 
> But what we could perhaps do with some kind of IRQF_SAMPLE_DUBIOUS would 
> be to improve the quality of the data in /dev/urandom if there's not 
> enough entropy available?
> 
> I have seen embedded systems with zero entropy, and dubious entropy 
> might there be better than no entropy at all.
> Or am I wrong on the latter?

There are two issues that people need to separate here:

- sampling noise
- estimating entropy in that noise

It certainly makes sense to sample network timing noise. It often does
not make sense to assume that there's any entropy in those timing
samples. For instance:

- our clock resolution may be low enough that an attacker can guess our
samples (ie it's simply HZ, very common in embedded land)
- the bus involved (ISA, peripheral bus, even slow PCI) may have the
same issue
- it may be heavily correlated with some other measurement (ie network
vs disk samples on file servers)

We currently assume that IRQF_SAMPLE_RANDOM means 'this is a completely
trusted unobservable entropy source' which is obviously wrong for
network devices but is right for some other classes of device.

I'd personally prefer to add a new interface, eg
add_network_randomness(), that internalized the wisdom of what to do 
with network samples. Similarly, the various 'input'-like devices that
use SAMPLE_RANDOM should be switched to go through the 'input'
interface.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH] drivers/net: remove network drivers' last few uses ofIRQF_SAMPLE_RANDOM

[Gilles Espinasse]

----- Original Message ----- 
From: "Adrian Bunk" <bunk@kernel.org>
To: "Gilles Espinasse" <g.esp@free.fr>
Cc: <netdev@vger.kernel.org>; <linux-kernel@vger.kernel.org>
Sent: Sunday, May 18, 2008 12:02 AM
Subject: Re: [PATCH] drivers/net: remove network drivers' last few uses
ofIRQF_SAMPLE_RANDOM


> On Fri, May 16, 2008 at 10:08:29PM +0200, Gilles Espinasse wrote:
> >
> > That's funny
> > It does look to disturb some kernel developper that ethernet may be
sniffed
> > to feed a RNG
> > even that could be very hard to reach any effective result in the case
of a
> > machine splitting different network segments.
> >
> > In the same time, it does not disturb openssl developpers to include non
> > initialised memory that may or may not be predictable to feed a RNG.
> > http://marc.info/?l=openssl-dev&m=121095151003011&w=2
>
> Why should it disturb them?
>
> As is explained in the email you quote it cannot make the RNG
> output worse.
>
Yes that's the whole point.
Why remove IRQF_SAMPLE_RANDOM if "it cannot make the RNG output worse."
We should not care if network traffic can be sniffed in some configurations
(plus sniffing could be very unlikely in some others).

There is some objections that I understand (less IRQ with NAPI or less IRQ
with more network traffic). But there is still the problem to have other
entropy supplier for any existing machines without hw_random chip.

For the few machines with a supported hw_random chip, rng-tools should do
the job (and far better)

I look at other possible entropy solutions proposed by Jeff Garzic
http://sourceforge.net/projects/egd
That's for system without /dev/random and linux has /dev/random.

http://sourceforge.net/projects/prngd
README say
"- If you have a UNIX version providing /dev/urandom or /dev/random you
  probably won't need PRNGD at all."

So I didn't find an operational replacement solution yet now.
I don't say something is not doable re-using parts of egd or prngd to feed
the entropy pool.

I had experiences with the entropy pool empty since 2.6.12.
I am running headless machines to compile with not much other activities
sometime.
On a headless machine running 2.6.11 kernel, openswan-1.0.10 was compiling
fine.
On that same machine upgraded to 2.6.12 vanillia kernel, package compilation
will wait I feed
the entropy pool by some actions (keyboard/console) during ipsec.secrets
generation.
Failed instruction was rsasigkey --verbose 2192

Problem was caused by the changes to feed the entropy pool on 2.6.12
2.6.25 fail the same way on that machine.
Each time any source to feed the entropy pool is removed, /dev/random
situation is always worst and DOS may happen.

I understand  IRQF_SAMPLE_RANDOM on a network card may be not the GREAT
solution.
In fact, this machine use via_rhine nic driver that does not have
SAMPLE_RANDOM collection even in 2.6.11 (and there not much traffic on this
machine when packages cache is up to date).

Are network drivers better without SAMPLE_RANDOM?
My understanding of openssl developper answer is same as yours :
"it cannot make the RNG output worse."
So why remove SAMPLE_RANDOM on network cards today if there is no
replacement solution ready for x% of machines running linux actually?

How many SAMPLE_RANDOM sources remain that have a chance to be run on the
average machine running linux?

Gilles

Re: [PATCH] drivers/net: remove network drivers' last few uses ofIRQF_SAMPLE_RANDOM

[Alan Cox]

> Why remove IRQF_SAMPLE_RANDOM if "it cannot make the RNG output worse."
> We should not care if network traffic can be sniffed in some configurations
> (plus sniffing could be very unlikely in some others).

It makes it much worse - it lies about entropy.

> My understanding of openssl developper answer is same as yours :
> "it cannot make the RNG output worse."

If you don't care about the quality of your "random" numbers then
use /dev/urandom. It's very simple.

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Andi Kleen]

Chris Peterson wrote:
>> Would people be ok with kernel auto-feeding for /dev/urandom only? I've
>> been pondering that and I think that would work just as well in practice
>>  given the facts above. Then you would still only get blocking
>> /dev/random with the user daemon, but that won't matter because all
>> the usual users don't rely on thatanyways.
> 
> Andi, can you please clarify what you mean by "auto-feeding
> /dev/urandom only" and "only get blocking /dev/random with the user
> daemon"? Are you suggesting that the kernel provides /dev/urandom and
> a userspace daemon (e.g. EGD) provides /dev/random?

What I meant was "only getting working blocking /dev/random
with the user mode daemon". /

The kernel would still provide /dev/random. But on systems
without much entropy (which is pretty common) it will block
often and be unusable unless you run some obscure user space
daemons which regularly refeed /dev/random from hw_random
and stops doing that if the FIPS test fails and makes /dev/random
unusable again.

> Also, if crypto apps like ssh and openssl use on "insecure"
> /dev/urandom, then who actually relies on /dev/random? For comparison,
> FreeBSD does not even (AFAIK) have /dev/urandom. FreeBSD's /dev/random
> is nonblocking (like Linux's /dev/urandom) and includes network
> entropy.

It's sad to say, but their implementation makes more sense than Linux's
(including the feeding in of network data)

I suspect that's the main reason I actually found that many /dev/random
users as I found during my research.

-Andi

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Andi Kleen]

> I think the big kicker is the difference between a session key (short
> lived) and a "real" key such as a gpg key that lives for a long time
> and is used for multile sessions and with different users (in crypto
> speak, Alice uses the same random key for Bob, Charlotte and David and
> potentially for a long time). For a session key, urandom is very likely
> an acceptable compromise; there's only so much data it's used for.
> For long term keys I can totally see why /dev/random is used instead.

We don't use it for most long term keys, e.g. ssh host keys. That is
because even on high entropy systems /dev/random usually doesn't work
during distribution installation because the system has not run long
enough to collect significant entropy yet.

See also the distinction between "user controlled visible cryptography"
and "background cryptography" I introduced in a earlier mail on that
topic. gpg can only get away with it because they rely on a high level
of user education (so requiring banging on keys is ok), but that's
not really an option for your normal "everyday background crypto",
including longer term keys.

So yes it's a nice theory, but without using the available randomness
sources always it doesn't work.

Instead I think just both urandom and random should try to rely
on TPMs and other hardware rngs and always get high quality bit noise.

-Andi

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Theodore Tso]

On Sun, May 18, 2008 at 12:13:35PM +0200, Andi Kleen wrote:
> We don't use it for most long term keys, e.g. ssh host keys. That is
> because even on high entropy systems /dev/random usually doesn't work
> during distribution installation because the system has not run long
> enough to collect significant entropy yet.

One thing which I'm not sure most people understand is that there
isn't that much difference between /dev/random and /dev/urandom.  They
are fed by the same sources, at the high level.  There is a single
large entropy pool which gets fed by whatever entropy sources the
kernel can get its hands on, which periodically catastrophically seeds
separate smaller pools used by /dev/random and /dev/urandom.  The only
difference is that /dev/random does entropy tracking; /dev/urandom
doesn't.

Hence, if you don't think the system hasn't run long enough to collect
significant entropy, you need to distinguish between "has run long
enough to collect entropy which is causes the entropy credits using a
somewhat estimation system where we try to be conservative such that
/dev/random will let you extract the number of bits you need", and
"has run long enough to collect entropy which is unpredictable by an
outside attacker such that host keys generated by /dev/urandom really
are secure".

See why the qualifying statements is so important?  If you really
believe that there isn't enough entropy after installing a
distribution, THEN YOU SHOULDN'T BE GENERATING SSH HOST KEYS.  The
problem is that the server scenario with no keyboard case is a really
nasty one.

> See also the distinction between "user controlled visible cryptography"
> and "background cryptography" I introduced in a earlier mail on that
> topic. gpg can only get away with it because they rely on a high level
> of user education (so requiring banging on keys is ok), but that's
> not really an option for your normal "everyday background crypto",
> including longer term keys.

No, this distinction is a specious one, I think.  It's really more a
level of paranoia.  People tend to be much more paranoid about their
own personal keys, at leasts if they are well trained.  Most people
don't bother verifying ssh host keys the first time they contact a
host, making them subject to a man-in-the-middle attack.  But most
people don't mind, by which we can deduce that most folks aren't as
careful about their ssh key.

If distributions really cared, they could very well introduce keyboard
banging as part of the install process; but no, being able to do an
unmanned, "turnkey" install is considered more important.  That says
something about how much they care about security right there.  (By
the way, if you are at least forcing the user to type in a root
password, having the distribution installer mix in the root password
into /dev/random would be a Really Good Idea; also, mixing in whatever
randomness it can get from the mouse during the install is also a
Really Good Idea.)

> Instead I think just both urandom and random should try to rely
> on TPMs and other hardware rngs and always get high quality bit noise.

Sure, if you can get access to a TPM or a hardware rng, that's
*always* a better choice.  But the reason for /dev/random and
/dev/urandom's existence is that hardware manufacturers have either
not included a real hardware RNG, or made it impossible to get to it.
(I *still* haven't figured out how to access my TPM on my Lenovo
laptops.  Anyone who can send me turn-key instructions, let me know
off-line.)  Intel used to provide a true hardware RNG in their
chipsets a few years ago (props to them), but then stopped after one
generation (boo, hiss).

If there is a way that we can at least seed /dev/random from the TPM
(without needing any magic enabling keys, etc.) once at boot time, and
then rely on what we can get from the environment, maybe we can do it
in the kernel without needing to move all of the TPM access/contention
control logic from userspace into the kernel.

Of course, even if we did this, it wouldn't solve the distro problem
(at least for distro's who truly care about the security of ssh host
keys), since not all systems have TPM's.

						- Ted

Re: [PATCH] drivers/net: remove network drivers' last few uses ofIRQF_SAMPLE_RANDOM

[Adrian Bunk]

On Sun, May 18, 2008 at 08:41:10AM +0200, Gilles Espinasse wrote:
> > On Fri, May 16, 2008 at 10:08:29PM +0200, Gilles Espinasse wrote:
> > >
> > > That's funny
> > > It does look to disturb some kernel developper that ethernet may be
> sniffed
> > > to feed a RNG
> > > even that could be very hard to reach any effective result in the case
> of a
> > > machine splitting different network segments.
> > >
> > > In the same time, it does not disturb openssl developpers to include non
> > > initialised memory that may or may not be predictable to feed a RNG.
> > > http://marc.info/?l=openssl-dev&m=121095151003011&w=2
> >
> > Why should it disturb them?
> >
> > As is explained in the email you quote it cannot make the RNG
> > output worse.
> >
> Yes that's the whole point.
> Why remove IRQF_SAMPLE_RANDOM if "it cannot make the RNG output worse."
> We should not care if network traffic can be sniffed in some configurations
> (plus sniffing could be very unlikely in some others).
>...
> Are network drivers better without SAMPLE_RANDOM?
> My understanding of openssl developper answer is same as yours :
> "it cannot make the RNG output worse."

The "it cannot make the RNG output worse." only applies to the OpenSSL 
case (one could argue whether it makes sense, but it can't do harm).

IRQF_SAMPLE_RANDOM and what was discussed in this email on the OpenSSL 
mailing list are two completely different subjects, and you completely 
miss the problem when you mix them.

> So why remove SAMPLE_RANDOM on network cards today if there is no
> replacement solution ready for x% of machines running linux actually?
>...

The replacement solution ready on all Linux machines today is for 
userspace to use /dev/urandom instead of /dev/random if feasible.

> Gilles

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] drivers/net: remove network drivers' last few uses ofIRQF_SAMPLE_RANDOM

[Theodore Tso]

On Sun, May 18, 2008 at 03:02:36PM +0300, Adrian Bunk wrote:
> > Yes that's the whole point.
> > Why remove IRQF_SAMPLE_RANDOM if "it cannot make the RNG output worse."
> > We should not care if network traffic can be sniffed in some configurations
> > (plus sniffing could be very unlikely in some others).
> >...
> > Are network drivers better without SAMPLE_RANDOM?
> > My understanding of openssl developper answer is same as yours :
> > "it cannot make the RNG output worse."
> 
> The "it cannot make the RNG output worse." only applies to the OpenSSL 
> case (one could argue whether it makes sense, but it can't do harm).

Actually, it applies here too.  Or it can be made to apply here.  If
people are concerned that for certain cards the entropy could
potentially be guessed by someone on the local network (although I
suspect it's still useful for protecting against someone who doesn't
have local network access), we could still sample the entropy, and
just not increment the entropy credit for /dev/random's sake.  It will
still put something into the entropy pool which is also used by
/dev/urandom.

> The replacement solution ready on all Linux machines today is for 
> userspace to use /dev/urandom instead of /dev/random if feasible.

Sampling interrupt entropy will definitely not hurt /dev/urandon, and
may help, especially in the freshly installed server case.  Especially
if it's using kickstart-style install, where there is no keyboard
entropy, sampling the interrupts as it pulls RPM's from the network
and/or the CD-ROM drive may be all that we have.

              	   	  	       	   	   - Ted

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Joe Korty]

On Sun, May 18, 2008 at 07:26:57AM -0400, Theodore Tso wrote:
> On Sun, May 18, 2008 at 12:13:35PM +0200, Andi Kleen wrote:
> > We don't use it for most long term keys, e.g. ssh host keys. That is
> > because even on high entropy systems /dev/random usually doesn't work
> > during distribution installation because the system has not run long
> > enough to collect significant entropy yet.
>  ...
> Hence, if you don't think the system hasn't run long enough to collect
> significant entropy, you need to distinguish between "has run long
> enough to collect entropy which is causes the entropy credits using a
> somewhat estimation system where we try to be conservative such that
> /dev/random will let you extract the number of bits you need", and
> "has run long enough to collect entropy which is unpredictable by an
> outside attacker such that host keys generated by /dev/urandom really
> are secure".
> ...
> If distributions really cared, they could very well introduce keyboard
> banging as part of the install process; but no, being able to do an
> unmanned, "turnkey" install is considered more important.  That says
> something about how much they care about security right there.

If the World really cared about security, every cpu chip
would supply a true source of random bits based on the
sampling some easily accessable quantum on-chip state,
such as the tiny fluctuations in current flow across
a resistance.  I suspect supplying this would be about
as expensive as supplying a true TSC driven directly by
the external clock -- that is, so close to zero as to
not matter.

Joe

Re: [PATCH] drivers/net: remove network drivers' last few uses ofIRQF_SAMPLE_RANDOM

[Adrian Bunk]

On Sun, May 18, 2008 at 08:24:10AM -0400, Theodore Tso wrote:
> On Sun, May 18, 2008 at 03:02:36PM +0300, Adrian Bunk wrote:
> > > Yes that's the whole point.
> > > Why remove IRQF_SAMPLE_RANDOM if "it cannot make the RNG output worse."
> > > We should not care if network traffic can be sniffed in some configurations
> > > (plus sniffing could be very unlikely in some others).
> > >...
> > > Are network drivers better without SAMPLE_RANDOM?
> > > My understanding of openssl developper answer is same as yours :
> > > "it cannot make the RNG output worse."
> > 
> > The "it cannot make the RNG output worse." only applies to the OpenSSL 
> > case (one could argue whether it makes sense, but it can't do harm).
> 
> Actually, it applies here too.  Or it can be made to apply here.  If
> people are concerned that for certain cards the entropy could
> potentially be guessed by someone on the local network (although I
> suspect it's still useful for protecting against someone who doesn't
> have local network access), we could still sample the entropy, and
> just not increment the entropy credit for /dev/random's sake.

The latter is exactly the difference between the two cases.

But Gilles was implying using IRQF_SAMPLE_RANDOM for gathering entropy 
was as harmless as OpenSSL mixing uninitialized memory into their RNG.

> It will
> still put something into the entropy pool which is also used by
> /dev/urandom.
> 
> > The replacement solution ready on all Linux machines today is for 
> > userspace to use /dev/urandom instead of /dev/random if feasible.
> 
> Sampling interrupt entropy will definitely not hurt /dev/urandon, and
> may help, especially in the freshly installed server case.  Especially
> if it's using kickstart-style install, where there is no keyboard
> entropy, sampling the interrupts as it pulls RPM's from the network
> and/or the CD-ROM drive may be all that we have.

No disagreement on this.

>               	   	  	       	   	   - Ted

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Andi Kleen]

> See why the qualifying statements is so important?  If you really
> believe that there isn't enough entropy after installing a
> distribution, THEN YOU SHOULDN'T BE GENERATING SSH HOST KEYS.  The
> problem is that the server scenario with no keyboard case is a really
> nasty one.

It's made worse by not feeding in the network interrupts.

I never quite understood the rationale behind that one either:
if you worry about someone else controlling the timing of these events,
why do you not worry about timings on the local system. e.g.
it's not that hard to predict with similar accuracy when a hard disk
interrupt happened when a local process read something from disk. Or
when the  keyboard/USB interrupt happened when you process keyboard input.

On the other hand if only the low bits of the time stamp counter
are used it should be still random enough in all cases because
real systems don't behave predictable down to ns levels.

> 
>> See also the distinction between "user controlled visible cryptography"
>> and "background cryptography" I introduced in a earlier mail on that
>> topic. gpg can only get away with it because they rely on a high level
>> of user education (so requiring banging on keys is ok), but that's
>> not really an option for your normal "everyday background crypto",
>> including longer term keys.
> 
> No, this distinction is a specious one, I think.  It's really more a
> level of paranoia.  

If people don't realize cryptography is used they can't really
have any paranoia. And you can only get away with paranoia requiring
significant user action (like banging on keys) if they realize that.

> People tend to be much more paranoid about their
> own personal keys, 

In this case I would say it's more the program authors because the users
don't really have any choice.

> That says
> something about how much they care about security right there. 

It's more a question on how practical security is. If security
gets too complicated nobody will use it.

[classical example of that is to force users to use unrememberable
"strong" passwords -- result is that they are just written down on
postit notes and pinned to monitors. Same effect here]

>> Instead I think just both urandom and random should try to rely
>> on TPMs and other hardware rngs and always get high quality bit noise.
> 
> Sure, if you can get access to a TPM or a hardware rng, that's
> *always* a better choice. 

Yes definitely, but the trouble is /dev/random does not use it by
default. So even if you have a working hardware RNG there's no
improvement on what comes out of /dev/u?random

 But the reason for /dev/random and
> /dev/urandom's existence is that hardware manufacturers have either
> not included a real hardware RNG, or made it impossible to get to it.
> (I *still* haven't figured out how to access my TPM on my Lenovo
> laptops.  Anyone who can send me turn-key instructions, let me know
> off-line.)  Intel used to provide a true hardware RNG in their
> chipsets a few years ago (props to them), but then stopped after one
> generation (boo, hiss).

Yes, but we don't use it either by default. So even if you have
such a chipset your /dev/random output isn't improved in any ways.

> If there is a way that we can at least seed /dev/random from the TPM
> (without needing any magic enabling keys, etc.) once at boot time, and
> then rely on what we can get from the environment, maybe we can do it
> in the kernel without needing to move all of the TPM access/contention
> control logic from userspace into the kernel.

Jeff's patch looked like a good start. I'll try to come up with
a complete patch series that auto feeds. The only system I have with a
TPM is a T61, let's see if trousers works on that.

There's also a couple of other problems here I believe, in particular
some of the kernel subsystems who get random numbers for their purpose
get it too early before there's any chance of seeing.

Also for a lot of kernel purposes (like the networking hash tables) it's
really wasteful to use the  precious entropy pool entropy.  It should
rather just seed some cryptographic PRNG once and then use output
from that for kernel purposes (or alternatively at least not
remove entropy credit from the random pool)

-Andi

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Benny Amorsen]

Theodore Tso <tytso@mit.edu> writes:

> also, mixing in whatever randomness it can get from the mouse during
> the install is also a Really Good Idea.)

I suspect that most server installations are completely automated. No
input device activity at all.


/Benny

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Helge Hafting]

Andi Kleen wrote:
> Herbert Xu wrote:
>   
>>
>> You can continue to feed data into the pool even if it fails the
>> test.  You just keep the entropy value same as before.
>>     
>
> You could do that, but what advantage would it have? I don't think it's
> worth running the FIPS test, or rather requiring the user land daemon
> and leaving behind most of the userbase just for this.
>   
Security through obfuscation?
Someone trying to predict the RNG can do so in theory, but if
they have to keep track of network timings, disk activity, and 5 other 
things, then
chances are that they fail ofen enough even if the attack is possible 
"in theory".

Helge Hafting

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Glen Turner]

On Thu, 2008-05-15 at 11:47 -0700, Kok, Auke wrote:

> How about the non-NAPI and non-throttled case? I would argue that without any irq
> mitigation we can still use SA_RANDOM.

You don't know what packet-shaping us upstream ISPs are using.
If we're shaping then we're moving packets in time so that they
arrive upon the ticking of a output queue playout clock.  That
is, packet arrival becomes periodic not random.

Linux has a class-based queuing implementation and this would
have a similar effect on outbound packets.

Nearby microwave ovens will add periodicy to the arrival
of WLAN data. It wouldn't shock me if multicast traffic
over WLANs (even if not addressed to the host in question)
had the same effect on unicast data.

TCP's behaviour hardly leads to random packet arrival times.
Take the probability of TCP data inter-packet arrival times.
It is at least a binomial distribution (and thus not a random
distribution, and thus not suitable for /dev/random):
 - Case A: first packet in a TCP window transmission
 - Case B: subsequent packets in a TCP window transmission
           (probability rises to near 1 that another packet
            will shortly follow this one).
TCP packet transmission times are also binomial and strongly
self-correlated.

Worst of all, packet arrivals and departures are remotely observable,
both to a classic remote attacker with access to the comms channel and
to another user on a multiuser host.  So even if packet arrivals and
departures were totally random they would not be of use, since the
"random" numbers which contribute to the key would be known to the
attacker.

Regards, Glen

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Glen Turner]

On Fri, 2008-05-16 at 22:34 +0200, Benny Amorsen wrote:

> Perhaps it would be possible to make most types of interrupts add
> entropy, but not credit any entropy?

You need to be certain that those sources are not able
to be influenced by a hostile party, otherwise the entropy
pool can be degraded to be less random over successive samples
than its entropy score suggests.  Interrupts do not meet that
test.

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Glen Turner]

On Fri, 2008-05-16 at 21:55 -0700, Chris Peterson wrote:
> * network drivers could use IRQF_SAMPLE_URANDOM

Is it permissable for /dev/urandom to degrade to be externally
influenced
by a hostile party?

For example, /dev/random has run out. So the output of /dev/urandom is
now
determined by previous values of /dev/random.  I then send in a stack of
network packets at regular intervals. So the output of /dev/urandom is
now greatly determined by those packets.  My search space for the
resulting
key is small since /dev/urandom appears to be random, but in fact is
periodic.

I'll also note that there is a huge number of periodic packets seen by
hosts on quiet networks -- such as a preparation VLAN where a system
administrator might choose to run up a new machine.

Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Glen Turner]

On Sun, 2008-05-18 at 19:53 +0200, Andi Kleen wrote:
> I never quite understood the rationale behind that one either:
> if you worry about someone else controlling the timing of these events,
> why do you not worry about timings on the local system. e.g.
> it's not that hard to predict with similar accuracy when a hard disk
> interrupt happened when a local process read something from disk. Or
> when the  keyboard/USB interrupt happened when you process keyboard input.

Accepting packets requires you to trust another party -- the network
provider and users of your host's networked services -- which you do
not have to trust otherwise.

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Benny Amorsen]

Glen Turner <gdt@gdt.id.au> writes:

> On Fri, 2008-05-16 at 22:34 +0200, Benny Amorsen wrote:
>
>> Perhaps it would be possible to make most types of interrupts add
>> entropy, but not credit any entropy?
>
> You need to be certain that those sources are not able
> to be influenced by a hostile party, otherwise the entropy
> pool can be degraded to be less random over successive samples
> than its entropy score suggests.

Not if we don't credit any entropy. /dev/random is engineered to be
safe against getting non-random input, as long as that input isn't
credited with entropy. /dev/random is even world writable by default.


/Benny

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Theodore Tso]

On Mon, May 26, 2008 at 12:39:49AM +0930, Glen Turner wrote:
> 
> For example, /dev/random has run out. So the output of /dev/urandom
> is now determined by previous values of /dev/random.  I then send in
> a stack of network packets at regular intervals. So the output of
> /dev/urandom is now greatly determined by those packets.  My search
> space for the resulting key is small since /dev/urandom appears to
> be random, but in fact is periodic.

That's not how it works.  Basically, as long as there is *some*
entropy in the system, even from the /var/lib/random-seed, or from
keyboard interrupts, or from mouse interrupts, which is unknown to the
attacker, in the worse case /dev/urandom will be no worse than a
cryptographic random number generator.

Even if you feed it huge amounts of known data, it won't allow you to
"influence" the cryptographic random number generator --- unless of
course SHA-1 is totally and thoroughly broken as a cryptographic hash
algorithm (invalidating all public key certificates and digital
signatures made using SHA-1 algorithm).

There is a reason why /dev/random is world-writeable; it's perfectly
safe to write arbitary amounts of data into /dev/random.  If the
attacker doesn't know what has been fixed into the entropy pool, his
life just got a lot harder.  If it is the attacker mixing known data
into the pool, it's no worse.

The problems with /dev/urandom only appear if there *all* of the data
is known by the attacker --- so all of the keyboard interrupts, all of
the network interrupts, all of the mouse interrupts, the initial
random seed file --- everything.  In practice the time when this has
come up is very early in the initial install process, where there is
no random seed file, and before any interrupt entropy has had a chance
to be mixed into the pool, particularly if it is a headless (i.e., no
keyboard, no mouse, no monitor) install process.

And here there is no magic bullet.  If you are doing a headless
install, and there is no entropy, and you don't have a way of
accessing a real hardware random number generator, THIS IS NOT THE
RIGHT TIME TO BE GENERATING SSH HOST KEYS.  

> I'll also note that there is a huge number of periodic packets seen by
> hosts on quiet networks -- such as a preparation VLAN where a system
> administrator might choose to run up a new machine.

If the attacker has the power to monitor your preparation/installation
network exactly when the machine is being installed, you probably have
worse problems on your hands --- for example, most distribution
installs off of CD include the RPM, and then get on the network to
grab the security updates.  If you have an attacker on your
preparation/install VLAN, they might be able to attack your machine
and install rootkit before you have a chance to install the security
errata RPM's.  That would be much simpler than trying to record all of
the network packet arrival times so you can try to guess the random
number generator!

		      	     	     	- Ted

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Alejandro Riveira Fernández]

El Sun, 25 May 2008 19:27:12 -0400
Theodore Tso <tytso@MIT.EDU> escribió:

> On Mon, May 26, 2008 at 12:39:49AM +0930, Glen Turner wrote:
> > 
> > For example, /dev/random has run out. So the output of /dev/urandom
> > is now determined by previous values of /dev/random.  I then send in
> > a stack of network packets at regular intervals. So the output of
> > /dev/urandom is now greatly determined by those packets.  My search
> > space for the resulting key is small since /dev/urandom appears to
> > be random, but in fact is periodic.
> 
> That's not how it works.  Basically, as long as there is *some*
> entropy in the system, even from the /var/lib/random-seed, or from
> keyboard interrupts, or from mouse interrupts, which is unknown to the
> attacker, in the worse case /dev/urandom will be no worse than a
> cryptographic random number generator.
> 
 [ ... ] 
 
 Just a shot in the dark... would hw sensors (raw data) chips be a good source
 of entropy for /dev/random ?? 

> 		      	     	     	- Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Bill Fink]

On Mon, 26 May 2008, Alejandro Riveira Fernández wrote:

> El Sun, 25 May 2008 19:27:12 -0400
> Theodore Tso <tytso@MIT.EDU> escribió:
> 
> > On Mon, May 26, 2008 at 12:39:49AM +0930, Glen Turner wrote:
> > > 
> > > For example, /dev/random has run out. So the output of /dev/urandom
> > > is now determined by previous values of /dev/random.  I then send in
> > > a stack of network packets at regular intervals. So the output of
> > > /dev/urandom is now greatly determined by those packets.  My search
> > > space for the resulting key is small since /dev/urandom appears to
> > > be random, but in fact is periodic.
> > 
> > That's not how it works.  Basically, as long as there is *some*
> > entropy in the system, even from the /var/lib/random-seed, or from
> > keyboard interrupts, or from mouse interrupts, which is unknown to the
> > attacker, in the worse case /dev/urandom will be no worse than a
> > cryptographic random number generator.
> > 
>  [ ... ] 
>  
>  Just a shot in the dark... would hw sensors (raw data) chips be a good source
>  of entropy for /dev/random ?? 

For systems with high resolution timers, even if an attacker has total
knowledge/control of the network, it doesn't seem realistically possible
for them to determine the low order bits of the nanosecond timer of
disk and network I/O system calls, if those were used as a source of
entropy.  I think this is a case of the (unrealistic) best being an
enemy of the common (and realistic) good.

Another idea that occured to me:  How about using the low order bits
of the instruction memory address being executed that was interrupted
by the HZ timer interrupt.  This also doesn't seem to be something
that an external attacker could realistically determine.  And a
combination of these approaches would be that much stronger, combined
of course with any other available entropy sources.

						-Bill

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Krzysztof Halasa]

Bill Fink <billfink@mindspring.com> writes:

> Another idea that occured to me:  How about using the low order bits
> of the instruction memory address being executed that was interrupted
> by the HZ timer interrupt.

Think of constant-instructions-length processors :-)
-- 
Krzysztof Halasa

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Bill Fink]

On Mon, 26 May 2008, Krzysztof Halasa wrote:

> Bill Fink <billfink@mindspring.com> writes:
> 
> > Another idea that occured to me:  How about using the low order bits
> > of the instruction memory address being executed that was interrupted
> > by the HZ timer interrupt.
> 
> Think of constant-instructions-length processors :-)

I'm not sure what you're driving at, but if it's that you shouldn't
use the very last 2 or 3 bits, then sure those should be excluded.
But that still leaves 9 or 10 bits at least in the page offset, and
that's being conservative in the number of address bits to sample.

						-Bill

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Ben Hutchings]

Bill Fink wrote:
> On Mon, 26 May 2008, Krzysztof Halasa wrote:
> 
> > Bill Fink <billfink@mindspring.com> writes:
> > 
> > > Another idea that occured to me:  How about using the low order bits
> > > of the instruction memory address being executed that was interrupted
> > > by the HZ timer interrupt.
> > 
> > Think of constant-instructions-length processors :-)
> 
> I'm not sure what you're driving at, but if it's that you shouldn't
> use the very last 2 or 3 bits, then sure those should be excluded.
> But that still leaves 9 or 10 bits at least in the page offset, and
> that's being conservative in the number of address bits to sample.

We would still need to exclude any tight loops which an attacker could
predict or influence a process to enter - the idle loop obviously, plus
udelay(), memcpy() and probably many other functions.  Some such loops may
be in userland and therefore unknown to us.  So there might not be nearly
as many bits of entropy in the program counter as could be naively
expected.  What's more, once userland is blocked on /dev/random, there is
no more entropy available from the program counter!

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Rick Jones]

> For systems with high resolution timers, even if an attacker has total
> knowledge/control of the network, it doesn't seem realistically possible
> for them to determine the low order bits of the nanosecond timer of
> disk and network I/O system calls, if those were used as a source of
> entropy. 

Around the same time I was working on getting the performance figures 
for the RNG in the Infineon TPM in the system I had, I tried, however 
briefly, to concoct a test using netperf and pulling the ITC on an 
Itanium processor to generate some randomness.  I'm not at all sure I 
was doing things correctly - I was pulling the bottom one to 4 bits of 
the ITC after each call to recv() of a TCP_RR test - but when I tried to 
feed the resulting trickle of data through diehard (which I may have 
been running poorly) it was giving nothing but a p value of 0.000000 
which while I don't grok the p-value itself, I understand that 
consistent value of 0.000000 is bad :(

So, I may have had a bad test case.  If someone has some suggestions for 
  a better test of the low-order-bits-of-the-interval-timer hypothesis 
I'd love to hear about them.

rick jones

Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

[Pavel Machek]

Hi!

> >  Just a shot in the dark... would hw sensors (raw data) chips be a good source
> >  of entropy for /dev/random ?? 
> 
> For systems with high resolution timers, even if an attacker has total
> knowledge/control of the network, it doesn't seem realistically possible
> for them to determine the low order bits of the nanosecond timer of
> disk and network I/O system calls, if those were used as a source of
> entropy.  I think this is a case of the (unrealistic) best being an
> enemy of the common (and realistic) good.
> 
> Another idea that occured to me:  How about using the low order bits
> of the instruction memory address being executed that was interrupted
> by the HZ timer interrupt.  This also doesn't seem to be something
> that an external attacker could realistically determine.  And a
> combination of these approaches would be that much stronger, combined
> of course with any other available entropy sources.

Well, I'd fear that hlt instruction in idle loop would be the one
interrupted most. But low bits of tsc at timer interrupt would be fine
entropy source.

..actually, bogomips varies a bit between boots, maybe we should hash
it into the pool?

Maybe we could even redo bogomips calculation at runtime and use low
bits as random numbers? :-).
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html