All of lore.kernel.org
 help / color / mirror / Atom feed
* [GIT PULL] random number generator updates for 6.1-rc1
@ 2022-10-03 17:44 Jason A. Donenfeld
  2022-10-10 17:48 ` Linus Torvalds
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Jason A. Donenfeld @ 2022-10-03 17:44 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel

Hi Linus,

Please pull the following random number generator updates for 6.1-rc1:

- Huawei reported that when they updated their kernel from 4.4 to something
  much newer, some userspace code they had broke, the culprit being the
  accidental removal of O_NONBLOCK from /dev/random way back in 5.6. It's been
  gone for over 2 years now and this is the first we've heard of it, but
  userspace breakage is userspace breakage, so O_NONBLOCK is now back.

- Use randomness from hardware RNGs much more often during early boot, at the
  same interval that crng reseeds are done, from Dominik.

- A semantic change in hardware RNG throttling, so that the hwrng framework
  can properly feed random.c with randomness from hardware RNGs that aren't
  specifically marked as creditable.

  A related patch coming to you via Herbert's hwrng tree depends on this one,
  not to compile, but just to function properly, so you may want to merge this
  PULL before that one.

- A fix to clamp credited bits from the interrupts pool to the size of the
  pool sample. This is mainly just a theoretical fix, as it'd be pretty hard
  to exceed it in practice.

- Oracle reported that InfiniBand TCP latency regressed by around 10-15% after
  a change a few cycles ago made at the request of the RT folks, in which we
  hoisted a somewhat rare operation (1 in 1024 times) out of the hard IRQ
  handler and into a workqueue, a pretty common and boring pattern.

  It turns out, though, that scheduling a worker from there has overhead of
  its own, whereas scheduling a timer on that same CPU for the next jiffy
  amortizes better and doesn't incur the same overhead.

  I also eliminated a cache miss by moving the work_struct (and subsequently,
  the timer_list) to below a critical cache line, so that the more critical
  members that are accessed on every hard IRQ aren't split between two cache
  lines.

- The boot-time initialization of the RNG has been split into two approximate
  phases: what we can accomplish before timekeeping is possible and what we
  can accomplish after. This winds up being useful so that we can use RDRAND
  to seed the RNG before CONFIG_SLAB_FREELIST_RANDOM=y systems initialize
  slabs, in addition to other early uses of randomness. The effect is that
  systems with RDRAND (or a bootloader seed) will never see any warnings at
  all when setting CONFIG_WARN_ALL_UNSEEDED_RANDOM=y. And kfence benefits from
  getting a better seed of its own.

- Small systems without much entropy sometimes wind up putting some truncated
  serial number read from flash into hostname, so contribute utsname changes
  to the RNG, without crediting. 

- Add smaller batches to serve requests for smaller integers, and make use of
  them when people ask for random numbers bounded by a given compile-time
  constant. This has positive effects all over the tree, most notably in
  networking and kfence.

- The original jitter algorithm intended (I believe) to schedule the timer for
  the next jiffy, not the next-next jiffy, yet it used mod_timer(jiffies + 1),
  which will fire on the next-next jiffy, instead of what I believe was
  intended, mod_timer(jiffies), which will fire on the next jiffy. So fix
  that. (If you did actually intend the next-next jiffy for this voodoo, let
  me know and I'll happily send you a new pull.)

- Fix a comment typo, from William.

Not in this PULL, but coming your way via other trees are several improvements
to bootloader seeding infrastructure. For 6.1, MIPS firmware environments will
be able to pass a random seed, m68k's support from 6.0 is generalized and
works with kexec, and the EFI stub will learn how to combine its own seed with
that of the previous EFI bootloader, so that bootloaders like systemd-boot can
manage seed files on various mediums and pass it along to the kernel safely.
I've also been working on wiring up these various seeds on the QEMU side. If
you haven't noticed, there's been a lot of effort toward enabling bootloaders
and firmwares to communicate a RNG seed safely with the kernel, somehow. The
hope is that providing some means of manufacturers and firmware writers to
provide entropy lays foundations for eliminating the boot-time entropy issue. 

Also worth noting is that in my Plumbers talk, I mentioned how add_device_
randomness() can be called on data or events that /might/ be random, but also
might not, and the RNG will benefit if it is random but won't be hurt if it's
not. So, as long as it doesn't impact performance, driver developers should
feel free to shuffle entropy into random.c with add_device_randomness() as
they see fit. Right after the talk ended, Bryan sent a patch for a wireless
driver to contribute some of its environmental noise to the RNG. Very cool.
This is in the same category as a patch a few months ago in the MMC tree
adding SD/MMC serial numbers to the pool, on the theory that this is often the
only unique thing on small boards. Little zero-cost improvements like this can
make a difference, so I'm happy to see them.

Thanks,
Jason

The following changes since commit 504c25cb76a9cb805407f7701b25a1fbd48605fa:

  Merge tag 'net-6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2022-09-22 10:58:13 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git tags/random-6.1-rc1-for-linus

for you to fetch changes up to d687772e6d2cbffd91fdda64812f79192c1e7ca0:

  random: fix typos in get_random_bytes() comment (2022-10-01 23:37:51 +0200)

----------------------------------------------------------------
Random number generator updates for Linux 6.1-rc1.
----------------------------------------------------------------

Dominik Brodowski (1):
      random: use hwgenerator randomness more frequently at early boot

Jason A. Donenfeld (12):
      random: restore O_NONBLOCK support
      random: throttle hwrng writes if no entropy is credited
      random: clamp credited irq bits to maximum mixed
      random: avoid reading two cache lines on irq randomness
      random: use expired timer rather than wq for mixing fast pool
      random: split initialization into early step and later step
      kfence: use better stack hash seed
      random: use init_utsname() instead of utsname()
      utsname: contribute changes to RNG
      random: add 8-bit and 16-bit batches
      prandom: make use of smaller types in prandom_u32_max
      random: schedule jitter credit for next jiffy, not in two jiffies

William Zijl (1):
      random: fix typos in get_random_bytes() comment

 drivers/char/mem.c      |   4 +-
 drivers/char/random.c   | 115 ++++++++++++++++++++++++++++--------------------
 include/linux/prandom.h |  17 ++++---
 include/linux/random.h  |   5 ++-
 init/main.c             |  17 ++++---
 kernel/sys.c            |   3 ++
 kernel/utsname_sysctl.c |   2 +
 mm/kfence/core.c        |   2 +-
 8 files changed, 98 insertions(+), 67 deletions(-)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [GIT PULL] random number generator updates for 6.1-rc1
  2022-10-03 17:44 [GIT PULL] random number generator updates for 6.1-rc1 Jason A. Donenfeld
@ 2022-10-10 17:48 ` Linus Torvalds
  2022-10-10 18:32   ` Jason A. Donenfeld
  2022-10-10 17:56 ` Linus Torvalds
  2022-10-10 18:48 ` pr-tracker-bot
  2 siblings, 1 reply; 6+ messages in thread
From: Linus Torvalds @ 2022-10-10 17:48 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: linux-kernel

On Mon, Oct 3, 2022 at 10:45 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> - The original jitter algorithm intended (I believe) to schedule the timer for
>   the next jiffy, not the next-next jiffy, yet it used mod_timer(jiffies + 1),
>   which will fire on the next-next jiffy, instead of what I believe was
>   intended, mod_timer(jiffies), which will fire on the next jiffy. So fix
>   that. (If you did actually intend the next-next jiffy for this voodoo, let
>   me know and I'll happily send you a new pull.)

Just as long as you verified that yes, it will actually do the next timer.

At some point we had timer logic that went "trigger timer callback
immediately if it was in the past". I didn't want to have to worry
about that, this the "jiffies + 1".

I suspect we long ago got rid of that "trigger immediately" because of
deadlocks, and that I was just being a worry-wart about behavior that
we haven't had for decades, so your patch looks fine. But you might
want to make sure.

                   Linus

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [GIT PULL] random number generator updates for 6.1-rc1
  2022-10-03 17:44 [GIT PULL] random number generator updates for 6.1-rc1 Jason A. Donenfeld
  2022-10-10 17:48 ` Linus Torvalds
@ 2022-10-10 17:56 ` Linus Torvalds
  2022-10-10 18:37   ` Jason A. Donenfeld
  2022-10-10 18:48 ` pr-tracker-bot
  2 siblings, 1 reply; 6+ messages in thread
From: Linus Torvalds @ 2022-10-10 17:56 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: linux-kernel

On Mon, Oct 3, 2022 at 10:45 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
>   Merge tag 'net-6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2022-09-22 10:58:13 -0700)
>
> for you to fetch changes up to d687772e6d2cbffd91fdda64812f79192c1e7ca0:
>
>   random: fix typos in get_random_bytes() comment (2022-10-01 23:37:51 +0200)

Oh, and I notice that since you sent your pull request, you've updated
that tag with a new commit for a fix.

That's fine, and hey, it took me a while to get to this pull request.

But I do wish you had notified me (a follow-up email just saying "hey,
that tag got updated for a fix" is fine for a small change like this,
a new pull request saying "this supercedes the previous one is
preferred for anything bigger), if only because the difference in what
I pull and what gets described makes me then go back and lok "what
exactly happened here?".

              Linus

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [GIT PULL] random number generator updates for 6.1-rc1
  2022-10-10 17:48 ` Linus Torvalds
@ 2022-10-10 18:32   ` Jason A. Donenfeld
  0 siblings, 0 replies; 6+ messages in thread
From: Jason A. Donenfeld @ 2022-10-10 18:32 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel, sultan

Hey Linus,

On Mon, Oct 10, 2022 at 10:48:42AM -0700, Linus Torvalds wrote:
> On Mon, Oct 3, 2022 at 10:45 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > - The original jitter algorithm intended (I believe) to schedule the timer for
> >   the next jiffy, not the next-next jiffy, yet it used mod_timer(jiffies + 1),
> >   which will fire on the next-next jiffy, instead of what I believe was
> >   intended, mod_timer(jiffies), which will fire on the next jiffy. So fix
> >   that. (If you did actually intend the next-next jiffy for this voodoo, let
> >   me know and I'll happily send you a new pull.)
> 
> Just as long as you verified that yes, it will actually do the next timer.
> 
> At some point we had timer logic that went "trigger timer callback
> immediately if it was in the past". I didn't want to have to worry
> about that, this the "jiffies + 1".
> 
> I suspect we long ago got rid of that "trigger immediately" because of
> deadlocks, and that I was just being a worry-wart about behavior that
> we haven't had for decades, so your patch looks fine. But you might
> want to make sure.

I checked this and it works. Sultan and I jumped pretty far down the
timers rabbit hole in the process of investigating 748bc4dd9e66
("random: use expired timer rather than wq for mixing fast pool"). If
you grep the kernel, expiring at "jiffies" is a fairly common pattern
too.

Jason

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [GIT PULL] random number generator updates for 6.1-rc1
  2022-10-10 17:56 ` Linus Torvalds
@ 2022-10-10 18:37   ` Jason A. Donenfeld
  0 siblings, 0 replies; 6+ messages in thread
From: Jason A. Donenfeld @ 2022-10-10 18:37 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel

Hi Linus,

On Mon, Oct 10, 2022 at 10:56:16AM -0700, Linus Torvalds wrote:
> On Mon, Oct 3, 2022 at 10:45 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> >   Merge tag 'net-6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2022-09-22 10:58:13 -0700)
> >
> > for you to fetch changes up to d687772e6d2cbffd91fdda64812f79192c1e7ca0:
> >
> >   random: fix typos in get_random_bytes() comment (2022-10-01 23:37:51 +0200)
> 
> Oh, and I notice that since you sent your pull request, you've updated
> that tag with a new commit for a fix.
> 
> That's fine, and hey, it took me a while to get to this pull request.
> 
> But I do wish you had notified me (a follow-up email just saying "hey,
> that tag got updated for a fix" is fine for a small change like this,
> a new pull request saying "this supercedes the previous one is
> preferred for anything bigger), if only because the difference in what
> I pull and what gets described makes me then go back and lok "what
> exactly happened here?".

Hah! Welp. I went back and forth in my mind all week over this, whether
to bother you, or just to see what happens. I was thinking that either
you'd notice, and not care, a script would pull until the "up to commit"
and leave that off, or the whole thing would explode. Anyway, I'll let
you know if that happens again. I've been reading tea leaves every day
trying to divine when you'd actually merge this. :)

This all reminds me: I've got some other changes staged, which I think I
might do for 6.1, which involve some treewide cleanups and some
coccinelle. My approximate plan was to rebase those patches on your
merge of this pull, add the additional conversions due to code not
currently in my tree, and then send you a pull based on that at the end
of the week. Does that seem like a reasonably strategy? Or should I wait
until after rc1? Or something else?

Jason

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [GIT PULL] random number generator updates for 6.1-rc1
  2022-10-03 17:44 [GIT PULL] random number generator updates for 6.1-rc1 Jason A. Donenfeld
  2022-10-10 17:48 ` Linus Torvalds
  2022-10-10 17:56 ` Linus Torvalds
@ 2022-10-10 18:48 ` pr-tracker-bot
  2 siblings, 0 replies; 6+ messages in thread
From: pr-tracker-bot @ 2022-10-10 18:48 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: Linus Torvalds, linux-kernel

The pull request you sent on Mon,  3 Oct 2022 19:44:31 +0200:

> https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git tags/random-6.1-rc1-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a890d1c657ecba73a7b28591c92587aef1be1888

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-10-10 18:48 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-03 17:44 [GIT PULL] random number generator updates for 6.1-rc1 Jason A. Donenfeld
2022-10-10 17:48 ` Linus Torvalds
2022-10-10 18:32   ` Jason A. Donenfeld
2022-10-10 17:56 ` Linus Torvalds
2022-10-10 18:37   ` Jason A. Donenfeld
2022-10-10 18:48 ` pr-tracker-bot

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.