[RFCv2 0/9] UEFI emulator for kexec

[Dave Young]

On Thu, 22 Aug 2024 at 18:51, Pingfan Liu <piliu at redhat.com> wrote:
>
> On Thu, Aug 22, 2024 at 2:17 PM Dave Young <dyoung at redhat.com> wrote:
> >
> > On Thu, 22 Aug 2024 at 13:42, Pingfan Liu <piliu at redhat.com> wrote:
> > >
> > > On Wed, Aug 21, 2024 at 10:27 PM Lennart Poettering
> > > <mzxreary at 0pointer.de> wrote:
> > > >
> > > > On Mo, 19.08.24 22:53, Pingfan Liu (piliu at redhat.com) wrote:
> > > >
> > > > > *** Background ***
> > > > >
> > > > > As more PE format kernel images are introduced, it post challenge to kexec to
> > > > > cope with the new format.
> > > > >
> > > > > In my attempt to add support for arm64 zboot image in the kernel [1],
> > > > > Ard suggested using an emulator to tackle this issue.  Last year, when
> > > > > Jan tried to introduce UKI support in the kernel [2], Ard mentioned the
> > > > > emulator approach again [3]
> > > >
> > > > Hmm, systemd's systemd-stub code tries to load certain "side-car"
> > > > files placed next to the UKI, via the UEFI file system APIs. What's
> > > > your intention with the UEFI emulator regarding that? The sidecars are
> > > > somewhat important, because that's how we parameterize otherwise
> > > > strictly sealed, immutable UKIs.
> > > >
> > > IIUC, you are referring to UKI addons.
> > >
> > > > Hence, what's the story there? implement some form of fs driver (for
> > > > what fs precisely?) in the emulator too?
> > > >
> > > As for addon, that is a missing part in this series. I have overlooked
> > > this issue. Originally, I thought that there was no need to implement
> > > a disk driver and vfat file system, just preload them into memory, and
> > > finally present them through the uefi API. I will take a closer look
> > > at it and chew on it.
> > >
> >
> > Hi Pingfan,
> >
> > If more and more stuff needs coming in,  not only the limited boot
> > services then it will be way too complicated and hard to maintain and
> > debug,  also the two kexec code paths are duplicated somehow. It is
> > really bad..
> >
> OK, I will try to keep things easier. And what do you mean about " two
> kexec code paths"?

I mean we have the EFI and non-EFI kexec implementation. Also for the
EFI kexec code for X86 there is something we passed from 1st kernel to
2nd kernel due to no EFI firmware phase, anyway this part can be
cleaned up if the emulator can be done gracefully.

>
> > I forgot why we can not just extract the kernel from UKI and then load
> > it directly,  if the embedded kernel is also signed it should be good?
> >
>
> I think the main concern is about the signature.

I thought for the minimum case of kdump, we may just live with kernel
signed only and leave the initrd/cmdline unsigned.   Anyway for kexec
reboot it is a problem.

>
> Thanks,
>
> Pingfan
>