mbox series

[0/2] random: fix write locking for crng_init

Message ID 20220205103458.133386-1-linux@dominikbrodowski.net
Headers show
Series random: fix write locking for crng_init | expand

Message

Dominik Brodowski Feb. 5, 2022, 10:34 a.m. UTC 
According to a comment in random.c, crng_init is protected by
primary_crng->lock. These two patches fix the locking for
writing tp (that is: increasing) crng_init in call sites where it
may matter. At rand_initialize() time (precisely: either in
crng_initialize_primary() or in crng_finalize_init()), crng_init
is set to 2 without the lock being held. However, then the
kernel is running with IRQs disabled and only the boot CPU
active (but not yet in PID 1).

Dominik Brodowski (2):
  random: fix locking in crng_fast_load()
  random: fix locking for crng_init in crng_reseed()

 drivers/char/random.c | 25 ++++++++++++++++++-------
 1 file changed, 18 insertions(+), 7 deletions(-)

Comments

Jason A. Donenfeld Feb. 5, 2022, 1:17 p.m. UTC | #1 
Hi Dominik,

Does this introduce a lock nesting inversion situation?

With your patch, crng_fast_load() now does:

    lock(primary_crng)
    invalidate_batched_entropy()
        lock(batch_lock)
        unlock(batch_lock)
    unlock(primary_crng)

While get_random_{u32,u64}() does:

    lock(batch_lock)
    extract_crng()
       lock(primary_crng)
       unlock(primary_crng)
    unlock(batch_lock)

Is this correct? If so, we might have to defer this patch until after
<https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/commit/?id=2dfab1b1>
or something like it lands, which attempts to get rid of the batched
entropy lock.

If that analysis seems right to you, I could pull this patch into that
development branch for poking and prodding.

Jason