Messages in this thread | | | Date | Sun, 18 May 2008 12:08:42 +0200 | From | Andi Kleen <> | 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
| |