On Wed, 20 Sept 2023 at 20:07, Dave Young <dyoung@xxxxxxxxxx> wrote: > > On Wed, 20 Sept 2023 at 18:50, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > On Wed, 20 Sept 2023 at 08:40, Dave Young <dyoung@xxxxxxxxxx> wrote: > > > > > > On Wed, 20 Sept 2023 at 15:43, Dave Young <dyoung@xxxxxxxxxx> wrote: > > > > > > > > > > In the end the only benefit this series brings is to extend the > > > > > > signature checking on the whole UKI except of just the kernel image. > > > > > > Everything else can also be done in user space. Compared to the > > > > > > problems described above this is a very small gain for me. > > > > > > > > > > Correct. That is the benefit of pulling the UKI apart in the > > > > > kernel. However having to sign the kernel inside the UKI defeats > > > > > the whole point. > > > > > > > > > > > > Pingfan added the zboot load support in kexec-tools, I know that he is > > > > trying to sign the zboot image and the inside kernel twice. So > > > > probably there are some common areas which can be discussed. > > > > Added Ard and Pingfan in cc. > > > > http://lists.infradead.org/pipermail/kexec/2023-August/027674.html > > > > > > > > > > Here is another thread of the initial try in kernel with a few more > > > options eg. some fake efi service helpers. > > > https://lore.kernel.org/linux-arm-kernel/ZBvKSis+dfnqa+Vz@xxxxxxxxxxxxxxxxxxxxxxxxxx/T/#m42abb0ad3c10126b8b3bfae8a596deb707d6f76e > > > > > > > Ard, thanks for the comments. > > > Currently, UKI's external interface is defined in terms of EFI > > services, i.e., it is an executable PE/COFF binary that encapsulates > > all the logic that performs the unpacking of the individual sections, > > and loads the kernel as a PE/COFF binary as well (i.e., via > > LoadImage/StartImage) > > > > As soon as we add support to Linux to unpack a UKI and boot the > > encapsulated kernel using a boot protocol other than EFI, we are > > painting ourselves into a corner, severely limiting the freedom of the > > UKI effort to make changes to the interfaces that were implementation > > details up to this point. > > Agreed, it seems UKI is more flexible and complex than the zboot, > we do need to carefully think about a better solution. > > > > > It also means that UKI handling in kexec will need to be taught about > > every individual architecture again, which is something we are trying > > to avoid with EFI support in general. Breaking the abstraction like > > this lets the cat out of the bag, and will add yet another variation > > of kexec that we will need to support and maintain forever. > > > > So the only way to do this properly and portably is to implement the > > minimal set of EFI boot services [0] that Linux actually needs to run > > its EFI stub (which is mostly identical to the set that UKI relies on > > afaict), and expose them to the kexec image as it is being loaded. > > This is not as bad as it sounds - I have some Rust code that could be > > used as an inspiration [1] and which could be reused and shared > > between architectures. > > Great! > > > > > This would also reduce/remove the need for a purgatory: loading a EFI > > binary in this way would run it up to the point were it calls > > ExitBootServices(), and the actual kexec would invoke the image as if > > it was returning from ExitBootServices(). > > > > The only fundamental problem here is the need to allocate large chunks > > of physical memory, which would need some kind of CMA support, I > > imagine? > > Hmm, I thought that your idea is to write the efi stub code in "purgatory" > so kexec can jump to it while rebooting then it will be able to access the > whole usable memory, but it seems you want an efi app run under linux > and somehow provide services to kexec? My EFI knowledge is incomplete > and outdated, If my understanding of your proposal is true how can it keep > running after switching to the new kernel stub? Oops, please ignore the quick reply and questioins, I apparently forgot that this is the kexec loading phase instead of the rebooting phase. Yes as you said CMA might be the only choice for that proposal. > > > > > Maybe we should do a BoF at LPC to discuss this further? > > It does deserve more discussion, unfortunately I will not be able to join LPC, > Philipp Rudo (cced) planned attend the conf, so I think you guys can > discuss together with > other people interested. I think I will watch the recordings or > joining virtually if possible. > > > > > [0] this is not as bad as it sounds: beyond a protocol database, a > > heap allocator and a memory map, there is actually very little needed > > to boot Linux via the EFI stub (although UKI needs > > LoadImage/StartImage as well) > > > > [1] https://github.com/ardbiesheuvel/efilite > > _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
