linux-kernel - [PATCH 1/1] urandom: handle signals immediately

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1417252349-808-1-git-send-email-xypron.glpk@gmx.de>
Date:	Sat, 29 Nov 2014 10:12:29 +0100
From:	Heinrich Schuchardt <xypron.glpk@....de>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org,
	Heinrich Schuchardt <xypron.glpk@....de>
Subject: [PATCH 1/1] urandom: handle signals immediately

Without the patch device /dev/urandom only considers signals when a
rescheduling of the thread is requested. This may imply that
signals will not be handled for time intervals in excess of 30s.

With the patch signals are handled in every round copying 10 bytes if more
than 256 bytes have been collected. This 256 byte limit ensures the
guarantee given by system call getrandom().

With the patch rescheduling may occur even when reading less than 257 bytes.
This restores the logic before the introduction of the getrandom() system
call. getrandom() provides no guarantee concerning rescheduling.

An example code for testing is provided in
https://lkml.org/lkml/2014/11/22/41

Signed-off-by: Heinrich Schuchardt <xypron.glpk@....de>
---
 drivers/char/random.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 04645c0..75e96c1 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1189,21 +1189,20 @@ static ssize_t extract_entropy_user(struct entropy_store *r, void __user *buf,
 {
 	ssize_t ret = 0, i;
 	__u8 tmp[EXTRACT_SIZE];
-	int large_request = (nbytes > 256);
 
 	trace_extract_entropy_user(r->name, nbytes, ENTROPY_BITS(r), _RET_IP_);
 	xfer_secondary_pool(r, nbytes);
 	nbytes = account(r, nbytes, 0, 0);
 
 	while (nbytes) {
-		if (large_request && need_resched()) {
-			if (signal_pending(current)) {
-				if (ret == 0)
-					ret = -ERESTARTSYS;
-				break;
-			}
+		/*
+		 * getrandom must not be interrupted by a signal while
+		 * reading up to 256 bytes.
+		 */
+		if (signal_pending(current) && ret > 256)
+			break;
+		if (need_resched())
 			schedule();
-		}
 
 		extract_buf(r, tmp);
 		i = min_t(int, nbytes, EXTRACT_SIZE);
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/