linux-kernel - Re: [PATCH] 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]

Date:	Sun, 18 May 2008 12:08:42 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Chris Peterson <cpeterso@...terso.com>
CC:	Herbert Xu <herbert@...dor.apana.org.au>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jeff Garzik <jeff@...zik.org>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	tpmdd-devel@...ts.sourceforge.net, tpm@...horst.net
Subject: Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last
 few uses of IRQF_SAMPLE_RANDOM

Chris Peterson wrote:
>> Would people be ok with kernel auto-feeding for /dev/urandom only? I've
>> been pondering that and I think that would work just as well in practice
>>  given the facts above. Then you would still only get blocking
>> /dev/random with the user daemon, but that won't matter because all
>> the usual users don't rely on thatanyways.
> 
> Andi, can you please clarify what you mean by "auto-feeding
> /dev/urandom only" and "only get blocking /dev/random with the user
> daemon"? Are you suggesting that the kernel provides /dev/urandom and
> a userspace daemon (e.g. EGD) provides /dev/random?

What I meant was "only getting working blocking /dev/random
with the user mode daemon". /

The kernel would still provide /dev/random. But on systems
without much entropy (which is pretty common) it will block
often and be unusable unless you run some obscure user space
daemons which regularly refeed /dev/random from hw_random
and stops doing that if the FIPS test fails and makes /dev/random
unusable again.

> Also, if crypto apps like ssh and openssl use on "insecure"
> /dev/urandom, then who actually relies on /dev/random? For comparison,
> FreeBSD does not even (AFAIK) have /dev/urandom. FreeBSD's /dev/random
> is nonblocking (like Linux's /dev/urandom) and includes network
> entropy.

It's sad to say, but their implementation makes more sense than Linux's
(including the feeding in of network data)

I suspect that's the main reason I actually found that many /dev/random
users as I found during my research.

-Andi

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