On Thu, 9 Jun 2022 at 11:03, Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > > Hi Ard, > > I'm trying to break the analysis down a bit to figure out what should be > done here. Can you tell me if any of these points are incorrect? > > Case 0) EFI fails to provide any randomness at all. > Result: nothing happens on kexec; add_bootloader_randomness() is > used by nobody. > > Case 1) EFI provides randomness. Parent kernel is trust_bootloader=y. > Child kernel is trust_bootloader=y. > Result: parent makes new seed for child, and everything works fine. > > Case 2) EFI provides randomness. Parent kernel is trust_bootloader=y. > Child kernel is trust_bootloader=n. > Result: parent makes new seed for child, which child doesn't > credit, but everything still works fine. > > Case 3) EFI provides randomness. Parent kernel is trust_bootloader=n. > Child kernel is trust_bootloader=n. > Result: parent makes new seed for child using a technically > uninitialized RNG that is still of EFI-quality, which child > doesn't credit, so everything still works fine. > > Case 4) EFI provides randomness. Parent kernel is trust_bootloader=n. > Child kernel is trust_bootloader=y. > Result: parent makes new seed for child using a technically > uninitialized RNG that is still of EFI-quality, which child then > credits. On the surface, this seems bad. But actually, the > randomness here is still at least as good as what EFI provided, > which is what trust_bootloader=y means anyway. So I think this > case is actually fine. > > Since all cases are fine, I don't think this patch is actually needed. > The interesting thing about this exercise, though, is that the thing > that enables this conclusion is the base case 0, where we notice that > kexec doesn't pass a seed if EFI isn't passing any randomness in the > first place. Were that not so, then case 4 would be dangerous. > Indeed. > The question I have is whether the same holds for how device tree is > doing things. There, they check rng_is_initialized(), which means the > worst is avoided, I suppose, but doing so precludes the nice properties > that EFI has for cases 3 and 4. Is there a way to do things better > there, or not really? > I suppose we could zero the existing rng-seed property instead of dropping it entirely, and only repopulate it if it existed in the first place. The only problem here is that the kernel itself is not in charge of instantiating the original rng-seed property - it is whatever the DT contained and DTs are often kept in files. But this just boils down to whether or not the DT seed can be trusted to begin with.
