[PATCH] random: fix 32MB+ reads from /dev/urandom

[PATCH] random: fix 32MB+ reads from /dev/urandom

[Alexey Dobriyan]

https://bugzilla.kernel.org/show_bug.cgi?id=80981

Steps to reproduce:

	strace dd if=/dev/urandom of=/dev/null bs=64M count=1

Before, dd did 1 read() syscall and returned full length.
Now, dd stops at 32 MB.

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---

	STABLE needs 79a8468747c5f95ed3d5ce8376a3e82e0c5857fc
	and this patch.

 drivers/char/random.c |   24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1377,20 +1377,32 @@ random_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
 }
 
 static ssize_t
-urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
+urandom_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
 {
-	int ret;
+	ssize_t ret;
 
 	if (unlikely(nonblocking_pool.initialized == 0))
 		printk_once(KERN_NOTICE "random: %s urandom read "
 			    "with %d bits of entropy available\n",
 			    current->comm, nonblocking_pool.entropy_total);
 
-	nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3));
-	ret = extract_entropy_user(&nonblocking_pool, buf, nbytes);
+	ret = 0;
+	while (count > 0) {
+		size_t count1;
+		ssize_t ret1;
+
+		count1 = min_t(size_t, count, INT_MAX >> (ENTROPY_SHIFT + 3));
+		ret1 = extract_entropy_user(&nonblocking_pool, buf, count1);
+		if (ret1 < 0)
+			return ret1;
 
-	trace_urandom_read(8 * nbytes, ENTROPY_BITS(&nonblocking_pool),
-			   ENTROPY_BITS(&input_pool));
+		trace_urandom_read(8 * count1, ENTROPY_BITS(&nonblocking_pool),
+				   ENTROPY_BITS(&input_pool));
+
+		buf += ret1;
+		count -= ret1;
+		ret += ret1;
+	}
 	return ret;
 }
 

Re: [PATCH] random: fix 32MB+ reads from /dev/urandom

[Theodore Ts'o]

I don't think this patch is worthwhile.  There is no legitimate reason
to be using such large reads like this, and read(2) is always allowed
to return a short read (for example, if a signal comes in while the
read is happening).  The only difference is that we are now guaranteed
to return a short-read if you try to read more than 32MB.  Given that
there is no valid reason to ask for more than 256 or maybe 512 bytes
at a time, I'm not particularly worried about this.

If you really care, you can ask dd keep reading after a short read by
using "iflag=fullblock".  

						- Ted

Re: [PATCH] random: fix 32MB+ reads from /dev/urandom

[Pavel Machek]

On Wed 2014-07-23 16:26:41, Theodore Ts'o wrote:
> I don't think this patch is worthwhile.  There is no legitimate reason
> to be using such large reads like this, and read(2) is always allowed
> to return a short read (for example, if a signal comes in while the
> read is happening).  The only difference is that we are now guaranteed
> to return a short-read if you try to read more than 32MB.  Given

Regression from previous versions would be the reason. I'm pretty sure
someone has that dd in the scripts somewhere. (And signals are not an
issue in dd case.)
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html