Bug 38527

Summary: /dev/random does not obey O_NONBLOCK flag
Product: Base System Reporter: Andreas Gustafsson <gson>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.5-STABLE   
Hardware: Any   
OS: Any   

Description Andreas Gustafsson 2002-05-24 23:50:01 UTC 
In FreeBSD 4.5, reads on /dev/random are nonblocking by default.
This is incompatible with both the NetBSD and the Linux
/dev/random. Reads should be nonblocking if and only if the
O_NONBLOCK flag was passed to open().

How-To-Repeat: Type "od -c </dev/random" and note that the od process exits
after printing a few bytes of random data.  Repeat on a NetBSD
or Linux system and note that od blocks until more entropy has
been gathered (e.g., after vigorous movement of the mouse).
Comment 1 Nate Lawson 2002-06-25 21:00:04 UTC 
This behavior is intentional and was changed some time ago.  If you want
to block on /dev/random waiting for bytes to be available, use
select/poll.

Followup discussion to -current.

-Nate
Comment 2 Andreas Gustafsson 2002-06-28 19:02:45 UTC 
Nate Lawson writes:
> This behavior is intentional and was changed some time ago.  If you want
> to block on /dev/random waiting for bytes to be available, use
> select/poll.

You've got to be kidding.  Why would you intentionally implement a
behaviour that is

 a) gratuitously different from every other implementation of
    /dev/random

 b) gratuitously different from every other character 
    device in the history of Unix by being nonblocking
    by default,

 c) not even correctly nonblocking, because when no data
    is available, read() on a nonblocking device is supposed
    to return -1 with errno=EWOULDBLOCK, but in the case
    of /dev/random, read() returns 0,

and

 d) undocumented?

-- 
Andreas Gustafsson, gson@nominum.com
Comment 3 njl freebsd_committer freebsd_triage 2002-08-16 09:48:00 UTC 
State Changed
From-To: open->suspended

Suspended since we've reached an impasse.  I tend to agree with the 
submitter but consensus is that non-blocking behavior is needed for user 
apps.  Submitter is encouraged to start a discussion on freebsd-hackers if 
he wishes to make a case for the original behavior.
Comment 4 bob 2004-10-17 19:26:08 UTC 
This bug appears to have been fixed. Or, at a minimum, the repro steps
fail to reproduce the problem on 5.3-beta5.

A brief code inspection of randomdev.c shows that the read function now
has logic to handle blocking. It even appears that it will return
EWOULDBLOCK if you have opened with the non-blocking option and no data
is available.

Someone else might want to take a brief look at this, verify it and
close it.

-Bob
Comment 5 K. Macy freebsd_committer freebsd_triage 2007-11-16 06:54:49 UTC 
State Changed
From-To: suspended->closed


Yarrow returns EWOULDBLOCK and nehemiah appears to not have a need 
for blocking.