Re: [PATCH] [resend] drivers/net: remove network drivers' last fewuses of IRQF_SAMPLE_RANDOM

[Martin Wilck]

Chris Peterson wrote:

> Remove network drivers' last few uses of theoretically-exploitable network 
> entropy. Only 12 net drivers are affected. Headless boxes should use a 
> more secure source of entropy, such as the userspace daemons rngd, clrngd, 
> egd, audio_entropyd, and/or video_entroyd.

I don't think that consensus has been reached on this subject yet. 
Re-reading this thread, it's obvious that there are two camps with 
conflicting opinions all the way through the community. Very little has 
changed since the debate in 2006.

Those who are in favor of this patch argue that random data from 
/dev/random must be absolutely, truly cryptographically reliable. That's 
fine as a concept, but it is not even remotely realistic in many 
real-world systems.

Think about disk randomness in times where more and more disks don't 
have mechanical heads. Think about caching RAID controllers, solid state 
disks, virtual disks, even iSCSI volumes! In general, modern "disks" are 
no more reliable as entropy source than network interfaces.

Either the low-level driver (knowing the actual hardware) must decide 
whether or not a device is a suitable source of randomness, or better 
even, the admin must judge that from his knowledge of the actual situation.

To make /dev/random truly solid, all devices that currently contribute 
entropy must be re-scrutinized. Whether or not they really generate 
entropy should be made configurable for administrators, this is a matter 
of policy, not an a-priory property of a device class. It should be an 
individual device property - some SCSI disks in a system may be 
considered reliable and others not, and the same would hold for network 
devices.

In the meantime, while /dev/random isn't what it's supposed to be, I 
pledge to keep IRQF_SAMPLE_RANDOM for network devices, or at least, make 
at a configurable option for headless systems.

egd, etc. are not an adequate replacement for network-generated 
randomness. They either use /dev/hw_random, which is only available on a 
few machines, or system statistics which can hardly count as "random 
noise". On the contrary, the statistics are 100% deterministic if the 
initial system state is known. The only way such data can become 
non-deterministic is through user or network input. User input is not 
available in the scenario we're talking about, and well - network input 
should't count, should it? It's not a proof if such data passes the FIPE 
or diehard tests. These tests are statistical and would be passed by 
totally deterministic data such as the sequence of digits of Pi.

Whatever comes out of this discussion, it's most important that some 
sort of consensus is reached that user space can rely on. The current 
situation is just inconsistent and confusing. I that sense, Chris' patch 
is good because it at least removes the inconsistency between network 
drivers. But I'd only find it acceptable as the first part of a patch 
series that tackles the complete entropy-generation infrastructure.

Regards
Martin

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