mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Linux Kernel Developers List <linux-kernel@vger.kernel.org>
Cc: hpa@zytor.com, joern@logfs.org, macro@linux-mips.org,
	ralf@linux-mips.org, dave.taht@gmail.com, blogic@openwrt.org,
	andrewmcgr@gmail.com, smueller@chronox.de, geert@linux-m68k.org,
	tg@mirbsd.de, "Theodore Ts'o" <tytso@mit.edu>
Subject: [PATCH, RFC 08/12] random: mix in architectural randomness earlier in extract_buf()
Date: Sun, 22 Sep 2013 16:38:54 -0400	[thread overview]
Message-ID: <1379882338-7209-9-git-send-email-tytso@mit.edu> (raw)
In-Reply-To: <1379882338-7209-1-git-send-email-tytso@mit.edu>

Previously if CPU chip had a built-in random number generator (i.e.,
RDRAND on newer x86 chips), we mixed it in at the very end of
extract_buf() using an XOR operation.

We now mix it in right after the calculate a hash across the entire
pool.  This has the advantage that any contribution of entropy from
the CPU's HWRNG will get mixed back into the pool.  In addition, it
means that if the HWRNG has any defects (either accidentally or
maliciously introduced), this will be mitigated via the non-linear
transform of the SHA-1 hash function before we hand out generated
output.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
 drivers/char/random.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index ba23d5c..6d5e8e6 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -993,6 +993,17 @@ static void extract_buf(struct entropy_store *r, __u8 *out)
 		sha_transform(hash.w, (__u8 *)(r->pool + i), workspace);
 
 	/*
+	 * If we have a architectural hardware random number
+	 * generator, mix that in, too.
+	 */
+	for (i = 0; i < LONGS(EXTRACT_SIZE); i++) {
+		unsigned long v;
+		if (!arch_get_random_long(&v))
+			break;
+		hash.l[i] ^= v;
+	}
+
+	/*
 	 * We mix the hash back into the pool to prevent backtracking
 	 * attacks (where the attacker knows the state of the pool
 	 * plus the current outputs, and attempts to find previous
@@ -1021,17 +1032,6 @@ static void extract_buf(struct entropy_store *r, __u8 *out)
 	hash.w[1] ^= hash.w[4];
 	hash.w[2] ^= rol32(hash.w[2], 16);
 
-	/*
-	 * If we have a architectural hardware random number
-	 * generator, mix that in, too.
-	 */
-	for (i = 0; i < LONGS(EXTRACT_SIZE); i++) {
-		unsigned long v;
-		if (!arch_get_random_long(&v))
-			break;
-		hash.l[i] ^= v;
-	}
-
 	memcpy(out, &hash, EXTRACT_SIZE);
 	memset(&hash, 0, sizeof(hash));
 }
-- 
1.7.12.rc0.22.gcdd159b


  parent reply	other threads:[~2013-09-22 20:39 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-22 20:38 [PATCH, RFC 00/12] random driver changes Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 01/12] random: run random_int_secret_init() run after all late_initcalls Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 02/12] random: Statically compute poolbitshift, poolbytes, poolbits Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 03/12] random: Allow fractional bits to be tracked Theodore Ts'o
2013-09-23  4:01   ` Theodore Ts'o
2013-09-23  4:03     ` H. Peter Anvin
2013-09-22 20:38 ` [PATCH, RFC 04/12] random: Account for entropy loss due to overwrites Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 05/12] random: fix the tracepoint for get_random_bytes(_arch) Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 06/12] random: optimize spinlock use in add_device_randomness() Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 07/12] random: allow architectures to optionally define random_get_entropy() Theodore Ts'o
2013-09-23 10:38   ` Stephan Mueller
2013-09-23 11:05     ` Theodore Ts'o
2013-09-22 20:38 ` Theodore Ts'o [this message]
2013-09-23  4:11   ` [PATCH, RFC 08/12] random: mix in architectural randomness earlier in extract_buf() H. Peter Anvin
2013-09-23  4:33     ` Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 09/12] random: optimize the entropy_store structure Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 10/12] random: cap the rate which the /dev/urandom pool gets reseeded Theodore Ts'o
2013-09-22 21:21   ` H. Peter Anvin
2013-09-22 21:40     ` Theodore Ts'o
2013-09-22 22:45       ` H. Peter Anvin
2013-09-22 23:23         ` Theodore Ts'o
2013-09-23  0:26           ` H. Peter Anvin
2013-09-22 20:38 ` [PATCH, RFC 11/12] random: speed up the fast_mix function by a factor of four Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 12/12] random: adjust the generator polynomials in the mixing function slightly Theodore Ts'o
2013-09-25 10:51   ` Jörg-Volker Peetz

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=1379882338-7209-9-git-send-email-tytso@mit.edu \
    --to=tytso@mit.edu \
    --cc=andrewmcgr@gmail.com \
    --cc=blogic@openwrt.org \
    --cc=dave.taht@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=hpa@zytor.com \
    --cc=joern@logfs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=smueller@chronox.de \
    --cc=tg@mirbsd.de \
    /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

all inboxes | Powered by JetHome®