linux-kernel - [GIT PULL] random number generator fixes for 5.18-rc2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20220407132839.496822-1-Jason@zx2c4.com>
Date:   Thu,  7 Apr 2022 15:28:39 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     linux-kernel@...r.kernel.org
Subject: [GIT PULL] random number generator fixes for 5.18-rc2

Hi Linus,

Please pull the following five fixes to the RNG for 5.18-rc2:

- Another fixup to the fast_init/crng_init split, this time in how much
  entropy is being credited, from Jan Varho.

- As discussed, we now opportunistically call try_to_generate_entropy() in
  /dev/urandom reads, as a replacement for the reverted commit. I opted to not
  do the more invasive wait_for_random_bytes() change at least for now,
  preferring to do something smaller and more obvious for the time being, but
  maybe that can be revisited as things evolve later.

- Userspace can use FUSE or userfaultfd or simply move a process to idle
  priority in order to make a read from the random device never complete,
  which breaks forward secrecy, fixed by overwriting sensitive bytes early on
  in the function.

- Jann Horn noticed that /dev/urandom reads were only checking for pending
  signals if need_resched() was true, a bug going back to the genesis commit,
  now fixed by always checking for signal_pending() and calling
  cond_resched(). This explains various noticeable signal delivery delays I've
  seen in programs over the years that do long reads from /dev/urandom.

- In order to be more like other devices (e.g. /dev/zero) and to mitigate the
  impact of fixing the above bug, which has been around forever (users have
  never really needed to check the return value of read() for medium-sized
  reads and so perhaps many didn't), we now move signal checking to the bottom
  part of the loop, and do so every PAGE_SIZE-bytes.

Thanks,
Jason

The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17:

  Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)

are available in the Git repository at:

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

for you to fetch changes up to e3c1c4fd9e6d14059ed93ebfe15e1c57793b1a05:

  random: check for signals every PAGE_SIZE chunk of /dev/[u]random (2022-04-07 01:36:37 +0200)

----------------------------------------------------------------
Random number generator fixes for Linux 5.18-rc2.
----------------------------------------------------------------

Jan Varho (1):
      random: do not split fast init input in add_hwgenerator_randomness()

Jann Horn (1):
      random: check for signal_pending() outside of need_resched() check

Jason A. Donenfeld (3):
      random: opportunistically initialize on /dev/urandom reads
      random: do not allow user to keep crng key around on stack
      random: check for signals every PAGE_SIZE chunk of /dev/[u]random

 drivers/char/random.c | 74 +++++++++++++++++++++++++++------------------------
 1 file changed, 39 insertions(+), 35 deletions(-)