public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: "Guozihua (Scott)" <guozihua@huawei.com>
Cc: linux-crypto@vger.kernel.org, luto@kernel.org, tytso@mit.edu,
	ebiggers@kernel.org
Subject: Re: Inquiry about the removal of flag O_NONBLOCK on /dev/random
Date: Tue, 19 Jul 2022 13:01:56 +0200	[thread overview]
Message-ID: <YtaPJPkewin5uWdn@zx2c4.com> (raw)
In-Reply-To: <13e1fa9d-4df8-1a99-ca22-d9d655f2d023@huawei.com>

Hi,

On Thu, Jul 14, 2022 at 03:33:47PM +0800, Guozihua (Scott) wrote:
> Recently we noticed the removal of flag O_NONBLOCK on /dev/random by 
> commit 30c08efec888 ("random: make /dev/random be almost like 
> /dev/urandom"), it seems that some of the open_source packages e.g. 
> random_get_fd() of util-linux and __getrandom() of glibc. The man page 
> for random() is not updated either.
> 
> Would anyone please kindly provide some background knowledge of this 
> flag and it's removal? Thanks!

I didn't write that code, but I assume it was done this way because it
doesn't really matter that much now, as /dev/random never blocks after
the RNG is seeded. And now a days, the RNG gets seeded with jitter
fairly quickly as a last resort, so almost nobody waits a long time.

Looking at the two examples you mentioned, the one in util-linux does
that if /dev/urandom fails, which means it's mostly unused code, and the
one in glibc is for GNU Hurd, not Linux. I did a global code search and
found a bunch of other instances pretty similar to the util-linux case,
where /dev/random in O_NONBLOCK mode is used as a fallback to
/dev/urandom, which means it's basically never used. (Amusingly one such
user of this pattern is Ted's pwgen code from way back at the turn of
the millennium.)

All together, I couldn't really find anywhere that the removal of
O_NONBLOCK semantics would actually pose a problem for, especially since
/dev/random doesn't block at all after being initialized. So I'm
slightly leaning toward the "doesn't matter, do nothing" course of
action.

But on the other hand, you did somehow notice this, so that's important
perhaps. How did you run into it? *Does* it actually pose a problem? Or
was this a mostly theoretical finding from perusing source code?
Something like the below diff would probably work and isn't too
invasive, but I think I'd prefer to leave it be unless this really did
break some userspace of yours. So please let me know.

Regards,
Jason

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 70d8d1d7e2d7..6f232ac258bf 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1347,6 +1347,10 @@ static ssize_t random_read_iter(struct kiocb *kiocb, struct iov_iter *iter)
 {
 	int ret;
 
+	if (!crng_ready() &&
+	    ((kiocb->ki_flags & IOCB_NOWAIT) || (kiocb->ki_filp->f_flags & O_NONBLOCK)))
+		return -EAGAIN;
+
 	ret = wait_for_random_bytes();
 	if (ret != 0)
 		return ret;


  parent reply	other threads:[~2022-07-19 11:02 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-14  7:33 Inquiry about the removal of flag O_NONBLOCK on /dev/random Guozihua (Scott)
2022-07-18  8:52 ` Guozihua (Scott)
2022-07-19  3:47   ` Eric Biggers
2022-07-19  8:06     ` Guozihua (Scott)
2022-07-19 11:01 ` Jason A. Donenfeld [this message]
2022-07-21  3:50   ` Guozihua (Scott)
2022-07-21  4:07     ` Eric Biggers
2022-07-21  6:44       ` Guozihua (Scott)
2022-07-21  6:50         ` Eric Biggers
2022-07-21 10:37           ` Jason A. Donenfeld
2022-07-21 11:30             ` Guozihua (Scott)
2022-07-26  7:43             ` Guozihua (Scott)
2022-07-26 11:08               ` Jason A. Donenfeld
2022-07-26 11:33                 ` Guozihua (Scott)
2022-07-28  8:24                   ` Guozihua (Scott)
2022-09-06  7:14                     ` Guozihua (Scott)
2022-09-06 10:16                     ` Jason A. Donenfeld
2022-09-07 13:03                       ` Jason A. Donenfeld
2022-09-08  3:31                         ` Guozihua (Scott)
2022-09-08  9:51                           ` Jason A. Donenfeld
2022-09-08 10:40                             ` Jason A. Donenfeld
2022-09-08 14:26                               ` [PATCH] random: restore O_NONBLOCK support Jason A. Donenfeld
2022-09-19 10:27                             ` Inquiry about the removal of flag O_NONBLOCK on /dev/random Guozihua (Scott)
2022-09-19 10:40                               ` Jason A. Donenfeld
2022-09-19 10:45                                 ` Guozihua (Scott)
2022-07-21 11:09         ` Theodore Ts'o
2022-07-21 11:30           ` Guozihua (Scott)

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=YtaPJPkewin5uWdn@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=ebiggers@kernel.org \
    --cc=guozihua@huawei.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=luto@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox