netdev - Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <482C8550.5000909@intel.com>
Date:	Thu, 15 May 2008 11:47:44 -0700
From:	"Kok, Auke" <auke-jan.h.kok@...el.com>
To:	Jeff Garzik <jeff@...zik.org>
CC:	Rick Jones <rick.jones2@...com>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Chris Peterson <cpeterso@...terso.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
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

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