Re: [PATCH] random: add blocking facility to urandom

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Thu, Sep 8, 2011 at 12:13 PM, David Miller <davem@xxxxxxxxxxxxx> wrote:
> From: Steve Grubb <sgrubb@xxxxxxxxxx>

>> This patch does not _break_ all existing applications. If a system were under attack,
>> they might pause momentarily, but they do not break. Please, try the patch and use a
>> nice large number like 2000000 and see for yourself. Right now, everyone arguing about
>> this breaking things have not tried it to see if in fact things do break and how they
>> break if they do.
> If the application holds a critical resource other threads want when it
> blocks on /dev/urandom, then your change breaks things.  I can come up
> with more examples if you like.
> Please get off this idea that you can just change the blocking behavior
> for a file descriptor and nothing of consequence will happen.

I know it's work porting userspace, but would anyone think that a new
char device to do this would be a good enough idea?  You obviously
already worked out methods to port things which normally use urandom
to use random to discover the problem, so most of the work should be
done.  I suggest /dev/jkrandom (since this is half way between
/dev/random and /dev/urandom and 'u' is the 21st letter it seemed
appropriate to use letters 10 and 11)

Thus userspace can decide what matters.  Always with entropy and
blocks often (random).  From good enough entropy and rarely blocks
(jkrandom).  Possibly from some entropy and never block (urandom).

To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

Add to Google