All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	kernel-hardening@lists.openwall.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Eric Biggers <ebiggers3@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	David Miller <davem@davemloft.net>,
	tglx@linutronix.de
Subject: Re: [PATCH] random: silence compiler warnings and fix race
Date: Fri, 16 Jun 2017 16:35:16 +0200	[thread overview]
Message-ID: <20170616143515.yn6oo6tvmcsrxidw@linutronix.de> (raw)
In-Reply-To: <20170614224526.29076-1-Jason@zx2c4.com>

On 2017-06-15 00:45:26 [+0200], Jason A. Donenfeld wrote:
> Odd versions of gcc for the sh4 architecture will actually warn about
> flags being used while uninitialized, so we set them to zero. Non crazy
> gccs will optimize that out again, so it doesn't make a difference.

that is minor

> Next, over aggressive gccs could inline the expression that defines
> use_lock, which could then introduce a race resulting in a lock
> imbalance. By using READ_ONCE, we prevent that fate. Finally, we make
> that assignment const, so that gcc can still optimize a nice amount.

Not sure about that, more below.

> Finally, we fix a potential deadlock between primary_crng.lock and
> batched_entropy_reset_lock, where they could be called in opposite
> order. Moving the call to invalidate_batched_entropy to outside the lock
> rectifies this issue.

and *that* is separate issue which has to pulled in for stable once it
has been addressed in Linus' tree.

> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> Ted -- the first part of this is the fixup patch we discussed earlier.
> Then I added on top a fix for a potentially related race.
> 
> I'm not totally convinced that moving this block to outside the spinlock
> is 100% okay, so please give this a close look before merging.
> 
> 
>  drivers/char/random.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index e870f329db88..01a260f67437 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -803,13 +803,13 @@ static int crng_fast_load(const char *cp, size_t len)
>  		p[crng_init_cnt % CHACHA20_KEY_SIZE] ^= *cp;
>  		cp++; crng_init_cnt++; len--;
>  	}
> +	spin_unlock_irqrestore(&primary_crng.lock, flags);
>  	if (crng_init_cnt >= CRNG_INIT_CNT_THRESH) {
>  		invalidate_batched_entropy();
>  		crng_init = 1;
>  		wake_up_interruptible(&crng_init_wait);
>  		pr_notice("random: fast init done\n");
>  	}
> -	spin_unlock_irqrestore(&primary_crng.lock, flags);
>  	return 1;

I wouldn't just push the lock one up as is but move that write part to
crng_init to remain within the locked section. Like that:

diff --git a/drivers/char/random.c b/drivers/char/random.c
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -804,12 +804,14 @@ static int crng_fast_load(const char *cp, size_t len)
 		cp++; crng_init_cnt++; len--;
 	}
 	if (crng_init_cnt >= CRNG_INIT_CNT_THRESH) {
-		invalidate_batched_entropy();
 		crng_init = 1;
+		spin_unlock_irqrestore(&primary_crng.lock, flags);
+		invalidate_batched_entropy();
 		wake_up_interruptible(&crng_init_wait);
 		pr_notice("random: fast init done\n");
+	} else {
+		spin_unlock_irqrestore(&primary_crng.lock, flags);
 	}
-	spin_unlock_irqrestore(&primary_crng.lock, flags);
 	return 1;
 }
 
@@ -842,13 +844,16 @@ static void crng_reseed(struct crng_state *crng, struct entropy_store *r)
 	memzero_explicit(&buf, sizeof(buf));
 	crng->init_time = jiffies;
 	if (crng == &primary_crng && crng_init < 2) {
-		invalidate_batched_entropy();
 		crng_init = 2;
+		spin_unlock_irqrestore(&primary_crng.lock, flags);
+
+		invalidate_batched_entropy();
 		process_random_ready_list();
 		wake_up_interruptible(&crng_init_wait);
 		pr_notice("random: crng init done\n");
+	} else {
+		spin_unlock_irqrestore(&primary_crng.lock, flags);
 	}
-	spin_unlock_irqrestore(&primary_crng.lock, flags);
 }
 
 static inline void crng_wait_ready(void)

>  }
>  
> @@ -2041,8 +2041,8 @@ static DEFINE_PER_CPU(struct batched_entropy, batched_entropy_u64);
>  u64 get_random_u64(void)
>  {
>  	u64 ret;
> -	bool use_lock = crng_init < 2;
> -	unsigned long flags;
> +	bool use_lock = READ_ONCE(crng_init) < 2;

Are use about that? I am not sure that the gcc will inline "crng_init"
read twice. It is not a local variable. READ_ONCE() is usually used
where gcc could cache a memory access but you do not want this. But hey!
If someone knows better I am here to learn.
One thing that this change does for sure is that crng_init is read very
early in the function while without READ_ONCE it is delayed _after_
arch_get_random_XXX(). So if arch_get_random_XXX() is around and works
you have one read for nothing.

> +	unsigned long flags = 0;
>  	struct batched_entropy *batch;
>  
>  #if BITS_PER_LONG == 64

Sebastian

WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	kernel-hardening@lists.openwall.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Eric Biggers <ebiggers3@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	David Miller <davem@davemloft.net>,
	tglx@linutronix.de
Subject: [kernel-hardening] Re: [PATCH] random: silence compiler warnings and fix race
Date: Fri, 16 Jun 2017 16:35:16 +0200	[thread overview]
Message-ID: <20170616143515.yn6oo6tvmcsrxidw@linutronix.de> (raw)
In-Reply-To: <20170614224526.29076-1-Jason@zx2c4.com>

On 2017-06-15 00:45:26 [+0200], Jason A. Donenfeld wrote:
> Odd versions of gcc for the sh4 architecture will actually warn about
> flags being used while uninitialized, so we set them to zero. Non crazy
> gccs will optimize that out again, so it doesn't make a difference.

that is minor

> Next, over aggressive gccs could inline the expression that defines
> use_lock, which could then introduce a race resulting in a lock
> imbalance. By using READ_ONCE, we prevent that fate. Finally, we make
> that assignment const, so that gcc can still optimize a nice amount.

Not sure about that, more below.

> Finally, we fix a potential deadlock between primary_crng.lock and
> batched_entropy_reset_lock, where they could be called in opposite
> order. Moving the call to invalidate_batched_entropy to outside the lock
> rectifies this issue.

and *that* is separate issue which has to pulled in for stable once it
has been addressed in Linus' tree.

> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> Ted -- the first part of this is the fixup patch we discussed earlier.
> Then I added on top a fix for a potentially related race.
> 
> I'm not totally convinced that moving this block to outside the spinlock
> is 100% okay, so please give this a close look before merging.
> 
> 
>  drivers/char/random.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index e870f329db88..01a260f67437 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -803,13 +803,13 @@ static int crng_fast_load(const char *cp, size_t len)
>  		p[crng_init_cnt % CHACHA20_KEY_SIZE] ^= *cp;
>  		cp++; crng_init_cnt++; len--;
>  	}
> +	spin_unlock_irqrestore(&primary_crng.lock, flags);
>  	if (crng_init_cnt >= CRNG_INIT_CNT_THRESH) {
>  		invalidate_batched_entropy();
>  		crng_init = 1;
>  		wake_up_interruptible(&crng_init_wait);
>  		pr_notice("random: fast init done\n");
>  	}
> -	spin_unlock_irqrestore(&primary_crng.lock, flags);
>  	return 1;

I wouldn't just push the lock one up as is but move that write part to
crng_init to remain within the locked section. Like that:

diff --git a/drivers/char/random.c b/drivers/char/random.c
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -804,12 +804,14 @@ static int crng_fast_load(const char *cp, size_t len)
 		cp++; crng_init_cnt++; len--;
 	}
 	if (crng_init_cnt >= CRNG_INIT_CNT_THRESH) {
-		invalidate_batched_entropy();
 		crng_init = 1;
+		spin_unlock_irqrestore(&primary_crng.lock, flags);
+		invalidate_batched_entropy();
 		wake_up_interruptible(&crng_init_wait);
 		pr_notice("random: fast init done\n");
+	} else {
+		spin_unlock_irqrestore(&primary_crng.lock, flags);
 	}
-	spin_unlock_irqrestore(&primary_crng.lock, flags);
 	return 1;
 }
 
@@ -842,13 +844,16 @@ static void crng_reseed(struct crng_state *crng, struct entropy_store *r)
 	memzero_explicit(&buf, sizeof(buf));
 	crng->init_time = jiffies;
 	if (crng == &primary_crng && crng_init < 2) {
-		invalidate_batched_entropy();
 		crng_init = 2;
+		spin_unlock_irqrestore(&primary_crng.lock, flags);
+
+		invalidate_batched_entropy();
 		process_random_ready_list();
 		wake_up_interruptible(&crng_init_wait);
 		pr_notice("random: crng init done\n");
+	} else {
+		spin_unlock_irqrestore(&primary_crng.lock, flags);
 	}
-	spin_unlock_irqrestore(&primary_crng.lock, flags);
 }
 
 static inline void crng_wait_ready(void)

>  }
>  
> @@ -2041,8 +2041,8 @@ static DEFINE_PER_CPU(struct batched_entropy, batched_entropy_u64);
>  u64 get_random_u64(void)
>  {
>  	u64 ret;
> -	bool use_lock = crng_init < 2;
> -	unsigned long flags;
> +	bool use_lock = READ_ONCE(crng_init) < 2;

Are use about that? I am not sure that the gcc will inline "crng_init"
read twice. It is not a local variable. READ_ONCE() is usually used
where gcc could cache a memory access but you do not want this. But hey!
If someone knows better I am here to learn.
One thing that this change does for sure is that crng_init is read very
early in the function while without READ_ONCE it is delayed _after_
arch_get_random_XXX(). So if arch_get_random_XXX() is around and works
you have one read for nothing.

> +	unsigned long flags = 0;
>  	struct batched_entropy *batch;
>  
>  #if BITS_PER_LONG == 64

Sebastian

  reply	other threads:[~2017-06-16 14:35 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-07 23:25 [PATCH v5 00/13] Unseeded In-Kernel Randomness Fixes Jason A. Donenfeld
2017-06-07 23:25 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-07 23:25 ` [PATCH v5 01/13] random: invalidate batched entropy after crng init Jason A. Donenfeld
2017-06-07 23:25   ` [kernel-hardening] " Jason A. Donenfeld
2017-06-14 19:28   ` Sebastian Andrzej Siewior
2017-06-14 19:28     ` [kernel-hardening] " Sebastian Andrzej Siewior
2017-06-14 22:33     ` Jason A. Donenfeld
2017-06-14 22:33       ` [kernel-hardening] " Jason A. Donenfeld
2017-06-16  8:31       ` Sebastian Andrzej Siewior
2017-06-16  8:31         ` [kernel-hardening] " Sebastian Andrzej Siewior
2017-06-16 12:12         ` Jason A. Donenfeld
2017-06-16 12:12           ` [kernel-hardening] " Jason A. Donenfeld
2017-06-16 14:36           ` Sebastian Andrzej Siewior
2017-06-16 14:36             ` [kernel-hardening] " Sebastian Andrzej Siewior
2017-06-14 22:45     ` [PATCH] random: silence compiler warnings and fix race Jason A. Donenfeld
2017-06-14 22:45       ` [kernel-hardening] " Jason A. Donenfeld
2017-06-16 14:35       ` Sebastian Andrzej Siewior [this message]
2017-06-16 14:35         ` [kernel-hardening] " Sebastian Andrzej Siewior
2017-06-17  0:39         ` Jason A. Donenfeld
2017-06-17  0:39           ` [kernel-hardening] " Jason A. Donenfeld
2017-06-19  7:45           ` Sebastian Andrzej Siewior
2017-06-19  7:45             ` [kernel-hardening] " Sebastian Andrzej Siewior
2017-06-19 20:55             ` Jason A. Donenfeld
2017-06-19 20:55               ` [kernel-hardening] " Jason A. Donenfeld
2017-06-20  6:44               ` Sebastian Andrzej Siewior
2017-06-20  6:44                 ` [kernel-hardening] " Sebastian Andrzej Siewior
2017-06-19 20:57       ` Jason A. Donenfeld
2017-06-19 20:57         ` [kernel-hardening] " Jason A. Donenfeld
2017-06-20  6:03         ` Theodore Ts'o
2017-06-20  6:03           ` [kernel-hardening] " Theodore Ts'o
2017-06-20  6:27           ` Joel Stanley
2017-06-20  6:59           ` Michael Ellerman
2017-06-20  8:14           ` Jason A. Donenfeld
2017-06-20  8:14             ` [kernel-hardening] " Jason A. Donenfeld
2017-06-20  8:33             ` Jeffrey Walton
2017-06-20  8:33               ` [kernel-hardening] " Jeffrey Walton
2017-06-20  8:53               ` Jason A. Donenfeld
2017-06-20  8:53                 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-20  9:36                 ` Theodore Ts'o
2017-06-20  9:36                   ` [kernel-hardening] " Theodore Ts'o
2017-06-20  9:49                   ` Jeffrey Walton
2017-06-20  9:49                     ` [kernel-hardening] " Jeffrey Walton
2017-06-20 17:50                     ` Sandy Harris
2017-06-20 18:14                       ` Kees Cook
2017-06-20 18:14                         ` Kees Cook
2017-06-20 20:09                         ` Jason A. Donenfeld
2017-06-20 20:09                           ` [kernel-hardening] " Jason A. Donenfeld
2017-06-20 20:09                           ` Jason A. Donenfeld
2017-06-20  9:49                   ` Jason A. Donenfeld
2017-06-20  9:49                     ` [kernel-hardening] " Jason A. Donenfeld
2017-06-20 23:38                     ` Theodore Ts'o
2017-06-20 23:38                       ` [kernel-hardening] " Theodore Ts'o
2017-06-20 23:54                       ` Jason A. Donenfeld
2017-06-20 23:54                         ` [kernel-hardening] " Jason A. Donenfeld
2017-06-21  0:03                         ` [PATCH] random: warn when kernel uses unseeded randomness Jason A. Donenfeld
2017-06-21  0:03                           ` [kernel-hardening] " Jason A. Donenfeld
2017-06-21  0:12                           ` Kees Cook
2017-06-21  0:12                             ` [kernel-hardening] " Kees Cook
2017-06-21  0:12                             ` Kees Cook
2017-06-21  6:06                           ` Michael Ellerman
2017-06-21  6:06                             ` [kernel-hardening] " Michael Ellerman
2017-06-21  6:06                             ` Michael Ellerman
2017-06-21 20:38                             ` Theodore Ts'o
2017-06-22  0:04                               ` Jason A. Donenfeld
2017-06-21 23:50                       ` [PATCH] random: silence compiler warnings and fix race Jeffrey Walton
2017-06-21 23:50                         ` [kernel-hardening] " Jeffrey Walton
2017-06-07 23:25 ` [PATCH v5 02/13] random: add synchronous API for the urandom pool Jason A. Donenfeld
2017-06-07 23:25   ` [kernel-hardening] " Jason A. Donenfeld
2017-06-07 23:25 ` [PATCH v5 03/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family Jason A. Donenfeld
2017-06-07 23:25   ` [kernel-hardening] " Jason A. Donenfeld
2017-06-07 23:25 ` [PATCH v5 04/13] security/keys: ensure RNG is seeded before use Jason A. Donenfeld
2017-06-07 23:25   ` [kernel-hardening] " Jason A. Donenfeld
2017-06-07 23:25 ` [PATCH v5 05/13] crypto/rng: ensure that the RNG is ready before using Jason A. Donenfeld
2017-06-07 23:25   ` [kernel-hardening] " Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 06/13] iscsi: ensure RNG is seeded before use Jason A. Donenfeld
2017-06-07 23:26   ` [kernel-hardening] " Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 07/13] ceph: ensure RNG is seeded before using Jason A. Donenfeld
2017-06-07 23:26   ` [kernel-hardening] " Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 08/13] cifs: use get_random_u32 for 32-bit lock random Jason A. Donenfeld
2017-06-07 23:26   ` [kernel-hardening] " Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 09/13] rhashtable: use get_random_u32 for hash_rnd Jason A. Donenfeld
2017-06-07 23:26   ` [kernel-hardening] " Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 10/13] net/neighbor: use get_random_u32 for 32-bit hash random Jason A. Donenfeld
2017-06-07 23:26   ` [kernel-hardening] " Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 11/13] net/route: use get_random_int for random counter Jason A. Donenfeld
2017-06-07 23:26   ` [kernel-hardening] " Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 12/13] bluetooth/smp: ensure RNG is properly seeded before ECDH use Jason A. Donenfeld
2017-06-07 23:26   ` [kernel-hardening] " Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 13/13] random: warn when kernel uses unseeded randomness Jason A. Donenfeld
2017-06-07 23:26   ` [kernel-hardening] " Jason A. Donenfeld

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=20170616143515.yn6oo6tvmcsrxidw@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=Jason@zx2c4.com \
    --cc=davem@davemloft.net \
    --cc=ebiggers3@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.