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.
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?
Jason
