klauskiwi
commented
3 years ago I decided to open this issue here as well, because I believe that a Petitboot workaround could be worked in parallel with the kexec() route (which could take some time since there's apparently a lack of interest in improving that).
In other words, for the console issue (or any other setting that are both in the DTB as well as in the kernel command-line), maybe there's a way we can have Petitboot append those instructions to the kernel command line, instead of trying to pass them through a DTB?
Other suggestions and thoughts are welcome.
(This issue has been originally submitted as a kexec-lite issue here: https://github.com/antonblanchard/kexec-lite/issues/15)
In Petitboot, we use the --dtb argument to pass a patched devicetree blob that may contain modifications caused by the boot hooks (https://github.com/open-power/petitboot/tree/master/utils/hooks). Some of those modifications may contain an adjustment of what the console device ([linux,]stdout property of the chosen/ node) should be.
The problem is that the new kexec_file_load() method apparently doesn't support this, and from a bit of research that I did (on the ARM64 implementation that I believe we share some commonalities with), it's not completely trivial to do so, because in a secure boot environment, giving complete control over the devicetree blob can be seen as a security opening (even if cmdline is as well and nobody cares about it so far).
Looks like ARM64 opted to allow the next kernel to inherit the devicetree blob from the current kernel (I think in ppc64 they all share the same memory region so that would work for us as well I guess) but before trying to change the entire architecture of how Petitboot implements dtb hooks, I was wanting to double-check that this is everyone's understanding of it as well, and what if any alternatives could be implemented.
tl;dr: kernel lockdown + kexec_file_load() broke Petitboot's ability to pass an alternative console to the next kernel, among other things.
Thanks,
-Klaus