All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulrich Drepper <drepper@redhat.com>
To: "Theodore Ts'o" <tytso@mit.edu>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: short read from /dev/urandom
Date: Thu, 13 Jan 2005 20:54:54 -0800	[thread overview]
Message-ID: <41E7509E.4030802@redhat.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

The /dev/urandom device is advertised as always returning the requested 
number of bytes.  Yet, it fails to do this under some situations. 
Compile this

int main (void)
{
   alarm (100);
   char buf[32];
   int fd = open ("/dev/urandom", 0);
   while (1)
     if (read (fd, buf, sizeof buf) != sizeof (buf))
       abort ();
}

with

   gcc -o r r.c -g -O2 -pg


Note the -pg at the end to enable profiling.  Running this code fails 
for me after less than a second.

The relevant code in the kernel is this 
(drivers/char/random.c:extract_entropy)

         while (nbytes) {
                 /*
                  * Check if we need to break out or reschedule....
                  */
                 if ((flags & EXTRACT_ENTROPY_USER) && need_resched()) {
                         if (signal_pending(current)) {
                                 if (ret == 0)
                                         ret = -ERESTARTSYS;
                                 break;
                         }


Here the loop is left prematurely if a signal is pending.

One solution is to redefine the /dev/urandom interface.  The problem is 
that this will cause program to fail.  I know since I found this while 
debugging such a program.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

             reply	other threads:[~2005-01-14  4:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-14  4:54 Ulrich Drepper [this message]
2005-01-14  5:56 ` short read from /dev/urandom David Wagner
2005-01-14  6:54   ` Ulrich Drepper
2005-01-14 19:55     ` David Wagner
2005-01-14 19:10 ` Theodore Ts'o
2005-01-14 21:04   ` Ulrich Drepper
2005-01-14 23:21     ` Theodore Ts'o
2005-01-15  2:36       ` H. Peter Anvin
2005-01-16  2:51         ` Matt Mackall
2005-01-16  3:18           ` H. Peter Anvin
2005-01-15  2:34     ` H. Peter Anvin
2005-01-19 15:48     ` Pavel Machek
2005-01-16  2:44 ` Matt Mackall
2005-01-16  3:58   ` Ulrich Drepper
2005-01-16  4:58     ` Matt Mackall
2005-01-16 13:23     ` Andries Brouwer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41E7509E.4030802@redhat.com \
    --to=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.