Messages in this thread | | | Date | Thu, 15 May 2008 11:47:44 -0700 | From | "Kok, Auke" <> | Subject | Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM |
| |
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
| |