[v3,05/13] security/keys: ensure RNG is seeded before use

Commit Message

Jason A. Donenfeld June 6, 2017, 12:51 a.m. UTC

Otherwise, we might use bad random numbers which, particularly in the
case of IV generation, could be quite bad. It makes sense to use the
synchronous API here, because we're always in process context (as the
code is littered with GFP_KERNEL and the like). However, we can't change
to using a blocking function in key serial allocation, because this will
block booting in some configurations, so here we use the more
appropriate get_random_u32, which will use RDRAND if available.

Signed-off-by: Jason A. Donenfeld <[e-mail]>
Cc: David Howells <[e-mail]>
Cc: Mimi Zohar <[e-mail]>
Cc: David Safford <[e-mail]>
---
 security/keys/encrypted-keys/encrypted.c |  8 +++++---
 security/keys/key.c                      | 16 ++++++++--------
 2 files changed, 13 insertions(+), 11 deletions(-)

Comments

David Howells June 6, 2017, 10:08 a.m. UTC | #1

Jason A. Donenfeld <[e-mail]> wrote:

> +		key->serial = get_random_u32() >> 1;

If this may sleep, it must be interruptible.

David

Jason A. Donenfeld June 6, 2017, 12:23 p.m. UTC | #2

On Tue, Jun 6, 2017 at 12:08 PM, David Howells <[e-mail]> wrote:
> Jason A. Donenfeld <[e-mail]> wrote:
>
>> +             key->serial = get_random_u32() >> 1;
>
> If this may sleep, it must be interruptible.

That won't sleep. I could have made it get_random_u32_wait(), but we'd
get into trouble at boottime. So instead, for now, I just use
get_random_u32 rather than get_random_bytes, which can use the
architectural random number generator, when the platform has one,
which is available early on.

Patch

diff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c
index 0010955d7876..d51a28fc5cd5 100644
--- a/security/keys/encrypted-keys/encrypted.c
+++ b/security/keys/encrypted-keys/encrypted.c
@@ -777,10 +777,12 @@  static int encrypted_init(struct encrypted_key_payload *epayload,
 
 	__ekey_init(epayload, format, master_desc, datalen);
 	if (!hex_encoded_iv) {
-		get_random_bytes(epayload->iv, ivsize);
+		ret = get_random_bytes_wait(epayload->iv, ivsize);
+		if (unlikely(ret))
+			return ret;
 
-		get_random_bytes(epayload->decrypted_data,
-				 epayload->decrypted_datalen);
+		ret = get_random_bytes_wait(epayload->decrypted_data,
+					    epayload->decrypted_datalen);
 	} else
 		ret = encrypted_key_decrypt(epayload, format, hex_encoded_iv);
 	return ret;
diff --git a/security/keys/key.c b/security/keys/key.c
index 455c04d80bbb..b72078e532f2 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -134,17 +134,15 @@  void key_user_put(struct key_user *user)
  * Allocate a serial number for a key.  These are assigned randomly to avoid
  * security issues through covert channel problems.
  */
-static inline void key_alloc_serial(struct key *key)
+static inline int key_alloc_serial(struct key *key)
 {
 	struct rb_node *parent, **p;
 	struct key *xkey;
 
-	/* propose a random serial number and look for a hole for it in the
-	 * serial number tree */
+	/* propose a non-negative random serial number and look for a hole for
+	 * it in the serial number tree */
 	do {
-		get_random_bytes(&key->serial, sizeof(key->serial));
-
-		key->serial >>= 1; /* negative numbers are not permitted */
+		key->serial = get_random_u32() >> 1;
 	} while (key->serial < 3);
 
 	spin_lock(&key_serial_lock);
@@ -170,7 +168,7 @@  static inline void key_alloc_serial(struct key *key)
 	rb_insert_color(&key->serial_node, &key_serial_tree);
 
 	spin_unlock(&key_serial_lock);
-	return;
+	return 0;
 
 	/* we found a key with the proposed serial number - walk the tree from
 	 * that point looking for the next unused serial number */
@@ -314,7 +312,9 @@  struct key *key_alloc(struct key_type *type, const char *desc,
 
 	/* publish the key by giving it a serial number */
 	atomic_inc(&user->nkeys);
-	key_alloc_serial(key);
+	ret = key_alloc_serial(key);
+	if (ret < 0)
+		goto security_error;
 
 error:
 	return key;