On Thu, Jan 13, 2022 at 07:13:29PM +0100, Jason A. Donenfeld wrote:
> From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
>
> commit f7e67b8e803185d0aabe7f29d25a35c8be724a78 upstream.
>
> Currently, if CONFIG_RANDOM_TRUST_BOOTLOADER is enabled, multiple calls
> to add_bootloader_randomness() are broken and can cause a NULL pointer
> dereference, as noted by Ivan T. Ivanov. This is not only a hypothetical
> problem, as qemu on arm64 may provide bootloader entropy via EFI and via
> devicetree.
>
> On the first call to add_hwgenerator_randomness(), crng_fast_load() is
> executed, and if the seed is long enough, crng_init will be set to 1.
> On subsequent calls to add_bootloader_randomness() and then to
> add_hwgenerator_randomness(), crng_fast_load() will be skipped. Instead,
> wait_event_interruptible() and then credit_entropy_bits() will be called.
> If the entropy count for that second seed is large enough, that proceeds
> to crng_reseed().
>
> However, both wait_event_interruptible() and crng_reseed() depends
> (at least in numa_crng_init()) on workqueues. Therefore, test whether
> system_wq is already initialized, which is a sufficient indicator that
> workqueue_init_early() has progressed far enough.
>
> If we wind up hitting the !system_wq case, we later want to do what
> would have been done there when wqs are up, so set a flag, and do that
> work later from the rand_initialize() call.
>
> Reported-by: Ivan T. Ivanov <iivanov@xxxxxxx>
> Fixes: 18b915ac6b0a ("efi/random: Treat EFI_RNG_PROTOCOL output as bootloader randomness")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
> [Jason: added crng_need_done state and related logic.]
> Signed-off-by: Jason A. Donenfeld <Jason@xxxxxxxxx>
> ---
> drivers/char/random.c | 59 ++++++++++++++++++++++++++++---------------
> 1 file changed, 38 insertions(+), 21 deletions(-)
Now queued up, thanks!
greg k-h
