All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>, Eric Biggers <ebiggers@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Marc Zyngier <maz@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mark Brown <broonie@kernel.org>,
	Andre Przywara <andre.przywara@arm.com>
Subject: Re: [PATCH] random: avoid arch_get_random_seed_long() when collecting IRQ randomness
Date: Tue, 17 Nov 2020 14:33:07 +0100	[thread overview]
Message-ID: <CAMj1kXEg+22pejvof-p_z9uxNnf4yv+4ohAsJAo_LmtQ_+Bfmg@mail.gmail.com> (raw)
In-Reply-To: <CAMj1kXGtxWk3Z4fxm=b5YMU1Dy2HfaOAynaMiMGKZx9vLArpmg@mail.gmail.com>

On Wed, 11 Nov 2020 at 09:19, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> (+ Eric)
>
> On Thu, 5 Nov 2020 at 16:29, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > When reseeding the CRNG periodically, arch_get_random_seed_long() is
> > called to obtain entropy from an architecture specific source if one
> > is implemented. In most cases, these are special instructions, but in
> > some cases, such as on ARM, we may want to back this using firmware
> > calls, which are considerably more expensive.
> >
> > Another call to arch_get_random_seed_long() exists in the CRNG driver,
> > in add_interrupt_randomness(), which collects entropy by capturing
> > inter-interrupt timing and relying on interrupt jitter to provide
> > random bits. This is done by keeping a per-CPU state, and mixing in
> > the IRQ number, the cycle counter and the return address every time an
> > interrupt is taken, and mixing this per-CPU state into the entropy pool
> > every 64 invocations, or at least once per second. The entropy that is
> > gathered this way is credited as 1 bit of entropy. Every time this
> > happens, arch_get_random_seed_long() is invoked, and the result is
> > mixed in as well, and also credited with 1 bit of entropy.
> >
> > This means that arch_get_random_seed_long() is called at least once
> > per second on every CPU, which seems excessive, and doesn't really
> > scale, especially in a virtualization scenario where CPUs may be
> > oversubscribed: in cases where arch_get_random_seed_long() is backed
> > by an instruction that actually goes back to a shared hardware entropy
> > source (such as RNDRRS on ARM), we will end up hitting it hundreds of
> > times per second.
> >
> > So let's drop the call to arch_get_random_seed_long() from
> > add_interrupt_randomness(), and instead, rely on crng_reseed() to call
> > the arch hook to get random seed material from the platform.
> >
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> >  drivers/char/random.c | 15 +--------------
> >  1 file changed, 1 insertion(+), 14 deletions(-)
> >
> > diff --git a/drivers/char/random.c b/drivers/char/random.c
> > index 2a41b21623ae..a9c393c1466d 100644
> > --- a/drivers/char/random.c
> > +++ b/drivers/char/random.c
> > @@ -1261,8 +1261,6 @@ void add_interrupt_randomness(int irq, int irq_flags)
> >         cycles_t                cycles = random_get_entropy();
> >         __u32                   c_high, j_high;
> >         __u64                   ip;
> > -       unsigned long           seed;
> > -       int                     credit = 0;
> >
> >         if (cycles == 0)
> >                 cycles = get_reg(fast_pool, regs);
> > @@ -1298,23 +1296,12 @@ void add_interrupt_randomness(int irq, int irq_flags)
> >
> >         fast_pool->last = now;
> >         __mix_pool_bytes(r, &fast_pool->pool, sizeof(fast_pool->pool));
> > -
> > -       /*
> > -        * If we have architectural seed generator, produce a seed and
> > -        * add it to the pool.  For the sake of paranoia don't let the
> > -        * architectural seed generator dominate the input from the
> > -        * interrupt noise.
> > -        */
> > -       if (arch_get_random_seed_long(&seed)) {
> > -               __mix_pool_bytes(r, &seed, sizeof(seed));
> > -               credit = 1;
> > -       }
> >         spin_unlock(&r->lock);
> >
> >         fast_pool->count = 0;
> >
> >         /* award one bit for the contents of the fast pool */
> > -       credit_entropy_bits(r, credit + 1);
> > +       credit_entropy_bits(r, 1);
> >  }
> >  EXPORT_SYMBOL_GPL(add_interrupt_randomness);
> >
> > --
> > 2.17.1
> >

Ping?

WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>, Eric Biggers <ebiggers@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Marc Zyngier <maz@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>,
	Andre Przywara <andre.przywara@arm.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] random: avoid arch_get_random_seed_long() when collecting IRQ randomness
Date: Tue, 17 Nov 2020 14:33:07 +0100	[thread overview]
Message-ID: <CAMj1kXEg+22pejvof-p_z9uxNnf4yv+4ohAsJAo_LmtQ_+Bfmg@mail.gmail.com> (raw)
In-Reply-To: <CAMj1kXGtxWk3Z4fxm=b5YMU1Dy2HfaOAynaMiMGKZx9vLArpmg@mail.gmail.com>

On Wed, 11 Nov 2020 at 09:19, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> (+ Eric)
>
> On Thu, 5 Nov 2020 at 16:29, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > When reseeding the CRNG periodically, arch_get_random_seed_long() is
> > called to obtain entropy from an architecture specific source if one
> > is implemented. In most cases, these are special instructions, but in
> > some cases, such as on ARM, we may want to back this using firmware
> > calls, which are considerably more expensive.
> >
> > Another call to arch_get_random_seed_long() exists in the CRNG driver,
> > in add_interrupt_randomness(), which collects entropy by capturing
> > inter-interrupt timing and relying on interrupt jitter to provide
> > random bits. This is done by keeping a per-CPU state, and mixing in
> > the IRQ number, the cycle counter and the return address every time an
> > interrupt is taken, and mixing this per-CPU state into the entropy pool
> > every 64 invocations, or at least once per second. The entropy that is
> > gathered this way is credited as 1 bit of entropy. Every time this
> > happens, arch_get_random_seed_long() is invoked, and the result is
> > mixed in as well, and also credited with 1 bit of entropy.
> >
> > This means that arch_get_random_seed_long() is called at least once
> > per second on every CPU, which seems excessive, and doesn't really
> > scale, especially in a virtualization scenario where CPUs may be
> > oversubscribed: in cases where arch_get_random_seed_long() is backed
> > by an instruction that actually goes back to a shared hardware entropy
> > source (such as RNDRRS on ARM), we will end up hitting it hundreds of
> > times per second.
> >
> > So let's drop the call to arch_get_random_seed_long() from
> > add_interrupt_randomness(), and instead, rely on crng_reseed() to call
> > the arch hook to get random seed material from the platform.
> >
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> >  drivers/char/random.c | 15 +--------------
> >  1 file changed, 1 insertion(+), 14 deletions(-)
> >
> > diff --git a/drivers/char/random.c b/drivers/char/random.c
> > index 2a41b21623ae..a9c393c1466d 100644
> > --- a/drivers/char/random.c
> > +++ b/drivers/char/random.c
> > @@ -1261,8 +1261,6 @@ void add_interrupt_randomness(int irq, int irq_flags)
> >         cycles_t                cycles = random_get_entropy();
> >         __u32                   c_high, j_high;
> >         __u64                   ip;
> > -       unsigned long           seed;
> > -       int                     credit = 0;
> >
> >         if (cycles == 0)
> >                 cycles = get_reg(fast_pool, regs);
> > @@ -1298,23 +1296,12 @@ void add_interrupt_randomness(int irq, int irq_flags)
> >
> >         fast_pool->last = now;
> >         __mix_pool_bytes(r, &fast_pool->pool, sizeof(fast_pool->pool));
> > -
> > -       /*
> > -        * If we have architectural seed generator, produce a seed and
> > -        * add it to the pool.  For the sake of paranoia don't let the
> > -        * architectural seed generator dominate the input from the
> > -        * interrupt noise.
> > -        */
> > -       if (arch_get_random_seed_long(&seed)) {
> > -               __mix_pool_bytes(r, &seed, sizeof(seed));
> > -               credit = 1;
> > -       }
> >         spin_unlock(&r->lock);
> >
> >         fast_pool->count = 0;
> >
> >         /* award one bit for the contents of the fast pool */
> > -       credit_entropy_bits(r, credit + 1);
> > +       credit_entropy_bits(r, 1);
> >  }
> >  EXPORT_SYMBOL_GPL(add_interrupt_randomness);
> >
> > --
> > 2.17.1
> >

Ping?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2020-11-17 13:33 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-05 15:29 [PATCH] random: avoid arch_get_random_seed_long() when collecting IRQ randomness Ard Biesheuvel
2020-11-05 15:29 ` Ard Biesheuvel
2020-11-11  8:19 ` Ard Biesheuvel
2020-11-11  8:19   ` Ard Biesheuvel
2020-11-11  9:45   ` André Przywara
2020-11-11  9:45     ` André Przywara
2020-11-11 10:05     ` Ard Biesheuvel
2020-11-11 10:05       ` Ard Biesheuvel
2020-11-11 10:46       ` André Przywara
2020-11-11 10:46         ` André Przywara
2020-11-11 11:48         ` Ard Biesheuvel
2020-11-11 11:48           ` Ard Biesheuvel
2020-11-17 13:33   ` Ard Biesheuvel [this message]
2020-11-17 13:33     ` Ard Biesheuvel
2021-01-04 19:09     ` Ard Biesheuvel
2021-01-04 19:09       ` Ard Biesheuvel
2021-01-10  9:45       ` Ard Biesheuvel
2021-01-10  9:45         ` Ard Biesheuvel
2021-01-10 13:55         ` Jason A. Donenfeld
2021-01-15 13:18         ` Jason A. Donenfeld
2021-01-15 13:18           ` Jason A. Donenfeld
2020-11-20  4:11   ` Eric Biggers
2020-11-20  4:11     ` Eric Biggers
2020-12-01 12:23     ` Ard Biesheuvel
2020-12-01 12:23       ` Ard Biesheuvel
2020-12-07  8:12       ` Ard Biesheuvel
2020-12-07  8:12         ` Ard Biesheuvel
2020-12-07 14:27       ` Jason A. Donenfeld
2020-12-07 14:27         ` Jason A. Donenfeld
2020-12-07 15:35         ` Ard Biesheuvel
2020-12-07 15:35           ` Ard Biesheuvel
2020-11-20 15:27 ` Marc Zyngier
2020-11-20 15:27   ` Marc Zyngier
2020-11-27 12:08   ` Ard Biesheuvel
2020-11-27 12:08     ` Ard Biesheuvel
2021-01-21 17:53 ` Will Deacon
2021-01-21 17:53   ` Will Deacon

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=CAMj1kXEg+22pejvof-p_z9uxNnf4yv+4ohAsJAo_LmtQ_+Bfmg@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=andre.przywara@arm.com \
    --cc=broonie@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.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.