Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 16 Jun 2017 10:31:12 +0200
From: Sebastian Andrzej Siewior <>
To: "Jason A. Donenfeld" <>
Cc: Theodore Ts'o <>,
	Linux Crypto Mailing List <>,
	LKML <>,,
	Greg Kroah-Hartman <>,
	Eric Biggers <>,
	Linus Torvalds <>,
	David Miller <>,
Subject: Re: [PATCH v5 01/13] random: invalidate batched entropy after crng

On 2017-06-15 00:33:12 [+0200], Jason A. Donenfeld wrote:
> There's a potential race that I fixed in my v5 of that patch set, but
> Ted only took v4, and for whatever reason has been to busy to submit
> the additional patch I already posted showing the diff between v4&v5.
> Hopefully he actually gets around to it and sends this for the next
> rc. Here it is:

So you replace "crng_init < 2" with use_lock instead. That is not what I
am talking about. Again:
->       crng_fast_load()	        spin_trylock_irqsave(&primary_crng.lock, )
->        invalidate_batched_entropy()  write_lock_irqsave(&batched_entropy_reset_lock, );

in that order while the code path
	get_random_uXX()                read_lock_irqsave(&batched_entropy_reset_lock, );
->       extract_crng()
->        _extract_crng()                spin_lock_irqsave(&crng->lock, );

which allocates the same lock in opposite order.
That means
  T1			T2
  crng_fast_load()	get_random_u64()
              *dead lock*

So T1 waits for batched_entropy_reset_lock holding primary_crng.lock and
T2 waits for primary_crng.lock holding batched_entropy_reset_lock.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.