Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' lastfew uses of IRQF_SAMPLE_RANDOM

[Andi Kleen]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/