linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: George Spelvin <linux@horizon.com>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH, RFC] random: introduce getrandom(2) system call
Date: Tue, 22 Jul 2014 00:44:09 -0400	[thread overview]
Message-ID: <20140722044409.GE24960@thunk.org> (raw)
In-Reply-To: <1405990940.28229.4.camel@localhost>

On Tue, Jul 22, 2014 at 03:02:20AM +0200, Hannes Frederic Sowa wrote:
> 
> Ted, would it make sense to specifiy a 512 byte upper bound limit for
> random entropy extraction (I am not yet convinced to do that for
> urandom) and in case the syscall should block we make sure that we
> extract the amount of bytes the user requested?

On some systems, it's still possible that with a large /dev/random
extraction, you could end up blocking for hours.  So either the
getrandom(2) syscall needs to be uninterruptible, which has one set of
problems (and not just the user typing ^C, but also things like being
able to process alarms, which is highly problematic indeed), or you
need to allow it to be interruptible by a signal, in which case
userspace needs to check the error return for things like EINTR
anyway.  And if you have to check the error return, you might as well
check the number of bytes returned.

Yes, one could in theory set up a new variant of "uninterruptible"
signals that only exited if the signal caused the process to exit, and
otherwise, forced a system call restart even if SA_INTERRUPTIBLE was
not set in sigalarim, but that's add *way* more complexity than this
deserves.

Basically, I view /dev/random as an advanced call, and someone who
uses it should know what they are doing.  It's not the default for a
reason.

						- Ted

  reply	other threads:[~2014-07-22  4:44 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-20 16:26 [PATCH, RFC] random: introduce getrandom(2) system call George Spelvin
2014-07-20 17:03 ` George Spelvin
2014-07-20 21:32   ` Hannes Frederic Sowa
2014-07-21 11:21     ` George Spelvin
2014-07-21 15:27       ` Hannes Frederic Sowa
2014-07-22  1:02         ` Hannes Frederic Sowa
2014-07-22  4:44           ` Theodore Ts'o [this message]
2014-07-22  9:49             ` Hannes Frederic Sowa
2014-07-22 22:59               ` Theodore Ts'o
2014-07-23  9:47                 ` Hannes Frederic Sowa
2014-07-23 11:52                   ` George Spelvin
2014-07-23 12:10                     ` Hannes Frederic Sowa
2014-07-30 12:50                       ` Pavel Machek
2014-07-20 17:24 ` Theodore Ts'o
  -- strict thread matches above, loose matches on Subject: below --
2014-07-17 18:48 Mark Kettenis
2014-07-17 20:35 ` Andy Lutomirski
2014-07-17 21:28   ` Theodore Ts'o
2014-07-17 21:37     ` Andy Lutomirski
2014-07-17 22:21   ` David Lang
2014-07-17  9:18 Theodore Ts'o
2014-07-17 10:57 ` Hannes Frederic Sowa
2014-07-17 12:52   ` Theodore Ts'o
2014-07-17 13:15     ` Hannes Frederic Sowa
2014-07-17 12:09 ` Tobias Klauser
2014-07-17 12:52   ` Theodore Ts'o
2014-07-17 16:12 ` Christoph Hellwig
2014-07-17 17:01   ` Theodore Ts'o
2014-07-17 17:05     ` Bob Beck
2014-07-17 17:34       ` Theodore Ts'o
2014-07-17 17:45         ` Bob Beck
2014-07-17 17:46           ` Bob Beck
2014-07-17 17:57             ` Bob Beck
2014-07-17 22:30           ` Theodore Ts'o
2014-07-17 19:56         ` Bob Beck
2014-07-21  0:25     ` Dwayne Litzenberger
2014-07-21  7:18       ` Theodore Ts'o
2014-07-17 19:31 ` Greg KH
2014-07-17 19:33 ` Greg KH
2014-07-17 19:48 ` Zach Brown
     [not found]   ` <20140717194812.GC24196-fypN+1c5dIyjpB87vu3CluTW4wlIGRCZ@public.gmane.org>
2014-07-17 20:54     ` Theodore Ts'o
     [not found]       ` <20140717205417.GT1491-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2014-07-17 21:39         ` Zach Brown
2014-07-17 20:27 ` Andy Lutomirski
     [not found]   ` <53C8319A.8090108-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
2014-07-17 21:14     ` Theodore Ts'o
2014-07-18 16:36 ` Rolf Eike Beer
2014-07-20 15:50 ` Andi Kleen
2014-07-20 17:06   ` Theodore Ts'o
2014-07-20 17:27 ` Andreas Schwab
2014-07-20 17:41   ` Theodore Ts'o
2014-07-21  6:18 ` Dwayne Litzenberger
2014-07-23  8:42 ` Manuel Schölling

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=20140722044409.GE24960@thunk.org \
    --to=tytso@mit.edu \
    --cc=hannes@stressinduktion.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@horizon.com \
    /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;
as well as URLs for NNTP newsgroup(s).