lkml.org 
[lkml]   [2008]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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



\
 
 \ /
  Last update: 2008-05-18 12:11    [W:0.115 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site