linux-kernel - [PATCH v2 0/9] random: cleanups around per-cpu crng & rdrand

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: <20220209011919.493762-1-Jason@zx2c4.com>
Date:   Wed,  9 Feb 2022 02:19:10 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     tytso@....edu, linux@...inikbrodowski.net, ebiggers@...nel.org,
        "Jason A. Donenfeld" <Jason@...c4.com>
Subject: [PATCH v2 0/9] random: cleanups around per-cpu crng & rdrand

This series tackles a few issues that are intermingled with each other:

- Using RDSEED when we can rather than using RDRAND.

- Making sure RDRAND/RDSEED input always goes through the mixer rather
  than being xor'd into our state directly, in part in order to prevent
  ridiculous hypothetical cpu backdoors, and in part because it makes it
  easier to model RDRAND/RDSEED as just another entropy input.

- Untangling the never ending headache that is kmalloc'd NUMA secondary
  CRNGs, and replacing these with leaner per-cpu ChaCha keys that don't
  have all the state troubles. There are other patches pending my review
  that take the current NUMA initialization code to yet another layer of
  complexity, sort of driving home the point to me that the current code
  is a can of worms. This patchset attempts a different direction there.

- Enforcing "fast key erasure" expansion always, and not relying on
  having a shared block counter that is bound to lead to troubles sooner
  or later.

- Nearly eliminating lock contention when several processes use the rng
  at the same time. WireGuard, for example, processes packets in
  parallel on all threads, and this packet processing requires frequent
  calls to get_random_bytes().

- Making sure we're never throwing away entropy from the irq handler,
  since fast key erasure means we're overwriting keys.

Because one design choice in here affects others, these issues are
tackled by this same patchset. It's roughly divided into "things with
RDSEED" and "things with struct crng", with the ordering of commits
being important.

Finally the series ends with a one-off patch removing an obsolete limit
on /dev/urandom, and making crng_slow_load() more robust.

v2 improves on v1 by adding the crng_{fast,slow}_load() improvements,
adding a lot of comments regarding fast key erasure, correcting other
comments, fixing the function signatures of two functions that return an
array, and fixing some basic logic flow in checking crng_ready().

Jason A. Donenfeld (9):
  random: use RDSEED instead of RDRAND in entropy extraction
  random: get rid of secondary crngs
  random: inline leaves of rand_initialize()
  random: ensure early RDSEED goes through mixer on init
  random: do not xor RDRAND when writing into /dev/random
  random: absorb fast pool into input pool after fast load
  random: use simpler fast key erasure flow on per-cpu keys
  random: use hash function for crng_slow_load()
  random: remove outdated INT_MAX >> 6 check in urandom_read()

 drivers/char/random.c | 699 ++++++++++++++++++------------------------
 1 file changed, 291 insertions(+), 408 deletions(-)

-- 
2.35.0