Chris Peterson wrote:Quoting David Miller's excellent summary: The argument is that if you have a diskless system not taking any keyboard or other input from the user, the network would be your only source of random number entropy. But on the flip side, if the network provides the entropy, this is externally influencable random number entropy and thus in theory exploitable. And furthermore, on-board random number generators are the real answer to this problem. Thus, the impasse. There are roughly equal arguments on both sides. Providing some entropy could be argued as better than nothing, but it could also be said that providing potentially exploitable entropy is in fact worse than none at all. </quote> I tend to push people to /not/ add IRQF_SAMPLE_RANDOM to new drivers, but I'm not interested in going on a pogrom with existing code. We all have better things to do with our time :) Jeff --
| Glauber de Oliveira Costa | [PATCH 08/79] [PATCH] use identify_boot_cpu |
| David Woodhouse | [PATCH v2] Stop pmac_zilog from abusing 8250's device numbers. |
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Jeremy Fitzhardinge | [PATCH 30 of 31] xen: no need for domU to worry about MCE/MCA |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Frans Pop | svc: failed to register lockdv1 RPC service (errno 97). |
