Re: [RFCv2 0/9] UEFI emulator for kexec

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 22, 2024 at 2:17 PM Dave Young <dyoung@xxxxxxxxxx> wrote:
>
> On Thu, 22 Aug 2024 at 13:42, Pingfan Liu <piliu@xxxxxxxxxx> wrote:
> >
> > On Wed, Aug 21, 2024 at 10:27 PM Lennart Poettering
> > <mzxreary@xxxxxxxxxxx> wrote:
> > >
> > > On Mo, 19.08.24 22:53, Pingfan Liu (piliu@xxxxxxxxxx) 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 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.

Thanks,

Pingfan






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux