random: fix crash on multiple early calls to add_bootloader_randomness() #4829
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
commit f7e67b8 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 <[email protected]> Fixes: 18b915a ("efi/random: Treat EFI_RNG_PROTOCOL output as bootloader randomness") Cc: [email protected] Signed-off-by: Dominik Brodowski <[email protected]> [Jason: added crng_need_done state and related logic.] Signed-off-by: Jason A. Donenfeld <[email protected]>
|
Again confirming that this patch does resolve #4828. |
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this pull request
Jan 27, 2022
See: raspberrypi/linux#4845 kernel: drm/vc4_hdmi: Add Broadcast RGB property to allow override of RGB range See: raspberrypi/linux#4850 kernel: Update rpi-display overlay See: raspberrypi/linux#4841 kernel: ARM: dts: BCM2711 AON_INTR2 generates IRQ edges See: raspberrypi/linux#4838 kernel: drivers: bcm2835_unicam: Disable trigger mode operation See: raspberrypi/linux#4834 kernel: random: fix crash on multiple early calls to add_bootloader_randomness See: raspberrypi/linux#4829
popcornmix
added a commit
to raspberrypi/rpi-firmware
that referenced
this pull request
Jan 27, 2022
See: raspberrypi/linux#4845 kernel: drm/vc4_hdmi: Add Broadcast RGB property to allow override of RGB range See: raspberrypi/linux#4850 kernel: Update rpi-display overlay See: raspberrypi/linux#4841 kernel: ARM: dts: BCM2711 AON_INTR2 generates IRQ edges See: raspberrypi/linux#4838 kernel: drivers: bcm2835_unicam: Disable trigger mode operation See: raspberrypi/linux#4834 kernel: random: fix crash on multiple early calls to add_bootloader_randomness See: raspberrypi/linux#4829
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a possible fix for #4828. Hat tip to @P33M for finding the upstream patch.
commit f7e67b8 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 [email protected]
Fixes: 18b915a ("efi/random: Treat EFI_RNG_PROTOCOL output as bootloader randomness")
Cc: [email protected]
Signed-off-by: Dominik Brodowski [email protected]
[Jason: added crng_need_done state and related logic.]
Signed-off-by: Jason A. Donenfeld [email protected]