From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: George Spelvin <linux@horizon.com>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
tytso@mit.edu
Subject: Re: [PATCH, RFC] random: introduce getrandom(2) system call
Date: Tue, 22 Jul 2014 03:02:20 +0200 [thread overview]
Message-ID: <1405990940.28229.4.camel@localhost> (raw)
In-Reply-To: <1405956426.2319.37.camel@localhost>
On Mo, 2014-07-21 at 17:27 +0200, Hannes Frederic Sowa wrote:
> On Mo, 2014-07-21 at 07:21 -0400, George Spelvin wrote:
> > > I don't like partial reads/writes and think that a lot of people get
> > > them wrong, because they often only check for negative return values.
> >
> > The v1 patch, which did it right IMHO, didn't do partial reads in the
> > case we're talking about:
> >
> > + if (count > 256)
> > + return -EINVAL;
>
> I checked and unfortunately it does not; 256 bytes is way too large to
> guarantee non-existence of partial reads. On a typical older system
> without rdrand/rdseed you would have to limit the amount of bytes to
> extract to about 32. That's way too low. That said, the 512 bytes check
> only in case of extracting bytes from blocking pool would serve no
> purpose.
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?
Having a quick look maybe something like this? Only compile tested and
maybe can still be simplified. It guarantees we don't do a partial write
to user space for sub 512 bytes requests.
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 2721543..c0db6f5 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1345,8 +1345,14 @@ static int arch_random_refill(void)
return n;
}
+enum blocking_mode {
+ NONBLOCKING,
+ SYSCALL_BLOCK,
+ DEV_RANDOM_BLOCK
+};
+
static ssize_t
-_random_read(int nonblock, char __user *buf, size_t nbytes)
+_random_read(enum blocking_mode mode, char __user *buf, size_t nbytes)
{
ssize_t n;
@@ -1361,7 +1367,7 @@ _random_read(int nonblock, char __user *buf, size_t nbytes)
trace_random_read(n*8, (nbytes-n)*8,
ENTROPY_BITS(&blocking_pool),
ENTROPY_BITS(&input_pool));
- if (n > 0)
+ if (mode != SYSCALL_BLOCK && n > 0)
return n;
/* Pool is (near) empty. Maybe wait and retry. */
@@ -1370,7 +1376,7 @@ _random_read(int nonblock, char __user *buf, size_t nbytes)
if (arch_random_refill())
continue;
- if (nonblock)
+ if (mode == NONBLOCKING)
return -EAGAIN;
wait_event_interruptible(random_read_wait,
@@ -1384,7 +1390,8 @@ _random_read(int nonblock, char __user *buf, size_t nbytes)
static ssize_t
random_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
{
- return _random_read(file->f_flags & O_NONBLOCK, buf, nbytes);
+ return _random_read(file->f_flags & O_NONBLOCK ? NONBLOCKING :
+ DEV_RANDOM_BLOCK, buf, nbytes);
}
static ssize_t
@@ -1534,8 +1541,6 @@ const struct file_operations urandom_fops = {
SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
unsigned int, flags)
{
- int r;
-
if (flags & ~(GRND_NONBLOCK|GRND_RANDOM))
return -EINVAL;
@@ -1543,7 +1548,8 @@ SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
count = INT_MAX;
if (flags & GRND_RANDOM)
- return _random_read(flags & GRND_NONBLOCK, buf, count);
+ return _random_read(flags & GRND_NONBLOCK ? NONBLOCKING :
+ SYSCALL_BLOCK, buf, count);
if (unlikely(nonblocking_pool.initialized == 0)) {
if (flags & GRND_NONBLOCK)
Bye,
Hannes
next prev parent reply other threads:[~2014-07-22 1:02 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 [this message]
2014-07-22 4:44 ` Theodore Ts'o
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=1405990940.28229.4.camel@localhost \
--to=hannes@stressinduktion.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
--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;
as well as URLs for NNTP newsgroup(s).