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: linux-kernel@vger.kernel.org, linux@dominikbrodowski.net,
	Sultan Alsawaf <sultan@kerneltoast.com>,
	Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH] random: invalidate crngs and batches on cpuhp teardown
Date: Mon, 14 Feb 2022 15:26:16 +0100	[thread overview]
Message-ID: <YgpmiMURsT3OQLtM@linutronix.de> (raw)
In-Reply-To: <20220214134838.980159-1-Jason@zx2c4.com>

On 2022-02-14 14:48:38 [+0100], Jason A. Donenfeld wrote:
> Now that we have a cpuhp teardown notifier, we can invalidate the keys
> used by the per-cpu crngs and the batches used by per-cpu batched
> entropy, so that if the cpus come back online, and the generation
> counter happens to have cycled all the way around to where it was
> before, it doesn't mistakenly use the old data. The chances of this
> happening are exceedingly rare, but since we now have the notifier
> setup, doing this is basically free.

Wasn't aware that random bits get bad over time ;)

> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Cc: Sultan Alsawaf <sultan@kerneltoast.com>
> Cc: Dominik Brodowski <linux@dominikbrodowski.net>
> Cc: Theodore Ts'o <tytso@mit.edu>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
>  drivers/char/random.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index df5aef93da34..ce199af9bc56 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1225,6 +1225,15 @@ int random_dead_cpu(unsigned int cpu)
>  	 * since the MIX_INFLIGHT flag will be cleared.
>  	 */
>  	per_cpu_ptr(&irq_randomness, cpu)->count = 0;
> +
> +	/*
> +	 * We also want to invalidate per-cpu crngs and batches,
> +	 * so that if the CPU does come back online, it uses
> +	 * fresh entropy.
> +	 */
> +	per_cpu_ptr(&crngs, cpu)->generation = ULONG_MAX;
> +	per_cpu_ptr(&batched_entropy_u32, cpu)->position = UINT_MAX;
> +	per_cpu_ptr(&batched_entropy_u64, cpu)->position = UINT_MAX;

I think if you want to do this, then it would also make sense to put it
into the startup callback. If there is an user doing get_random_u32()
then you would preload the "old" entropy. But on your way "online" you
would preload it with the new entropy.

>  	return 0;
>  }
>  

Sebastian

      parent reply	other threads:[~2022-02-14 14:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-14 13:48 [PATCH] random: invalidate crngs and batches on cpuhp teardown Jason A. Donenfeld
2022-02-14 14:00 ` Jason A. Donenfeld
2022-02-14 14:26 ` Sebastian Andrzej Siewior [this message]

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=YgpmiMURsT3OQLtM@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=Jason@zx2c4.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=sultan@kerneltoast.com \
    --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.