Jeff Garzik wrote:
quoted text
> 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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html