On Fri, Feb 14, 2020 at 11:00 AM Mark Salyzyn <salyzyn@xxxxxxxxxxx> wrote: > > On 2/14/20 5:49 AM, Rob Herring wrote: > > On Fri, Feb 14, 2020 at 12:10 AM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > >> Hi, > >> > >> The following series is bootconfig based implementation of > >> the rng_seed option patch originally from Mark Salyzyn. > >> Note that I removed unrelated command line fixes from this > >> series. > > Why do we need this? There's already multiple other ways to pass > > random seed and this doesn't pass the "too complex for the command > > line" argument you had for needing bootconfig. > > > > Rob > > Android is the use case I can vouch for. But also KVM. > > Android Cuttlefish is an emulated device used extensively in the testing > and development infrastructure for In-house, partner, and system and > application developers for Android. There is no bootloader, per-se. > Because of the Android GKI distribution, there is also no rng virtual > driver built in, it is loaded later as a module, too late for many > aspects of KASLR and networking. There is no Device Tree, it does > however have access to the content of the initrd image, and to the > command line for the kernel. The only convenient way to get early > entropy is going to have to be one of those two places. I'm familiar with Cuttlefish somewhat. Guess who got virtio-gpu working on Android[1]. :) I assume DT doesn't work for you because you need x86 builds, but doesn't QEMU use UEFI in that case which also has a mechanism for passing entropy. To clarify my question: Why do we need random seed in bootconfig rather than just the kernel command line? I'm not understanding why things changed from your original patch. > In addition, 2B Android devices on the planet, especially in light of > the Android GKI distribution were everything that is vendor created is > in a module, needs a way to collect early entropy prior to module load > and pass it to the kernel. Yes, they do have access to the recently > added Device Tree approach, and we expect them to use it, as I have an > active backport for the mechanism into the Android 4.19 and 5.4 kernels. > There may also be some benefit to allowing the 13000 different > bootloaders an option to use bootconfig as a way of propagating the much > needed entropy to their kernels. I could make a case to also allow them > command line as another option to relieve their development stress to > deliver product, but we can stop there. Regardless, this early entropy > has the benefit of greatly improving security and precious boot time. We're going to update 13000 bootloaders to understand bootconfig rather than use the infrastructure already in place (DT and/or command line)? bootconfig is an ftrace feature only IMO. If it's more than that, I imagine there will be some opinions about that. Adding new bootloader-kernel interfaces is painful and not something to just add without much review. Rob
