[RFCv2 0/9] UEFI emulator for kexec

[Jan Hendrik Farr]

On 22 18:45:38, Pingfan Liu wrote:
> On Thu, Aug 22, 2024 at 4:23 PM Lennart Poettering <mzxreary at 0pointer.de> wrote:
> >
> > On Do, 22.08.24 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.
> >
> > Yeah, UKI addons, as well as credential files, and sysext/confext
> > DDIs.
> >
> > The addons are the most interesting btw, because we load them into
> > memory as PE files, and ask the UEFI to authenticate them.
> >
> > > > 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.
> >
> > It doesn't have to be VFAT btw. It just has to be something. For
> > example, it might suffice to take these files, pack them up as cpio or
> > so and pass them along with the UEFI execution. The UEFI emulator
> > would then have to expose them as a file system then.
> >
> > We are not talking of a bazillion of files here, it's mostly a
> > smallish number of sidecar files I'd expect.
> >
> Yes, I think about using <key, value>, where key is the file path,
> value is the file content.
> 
> > > > And regarding tpm? tpms require drivers and i guess at the moment uefi
> > > > emulator would run those aren't available anymore? but we really
> > > > should do a separator measurement then. (also there needs to be some
> > > > way to pass over measurement log of that measurement?)
> > >
> > > It is a pity that it is a common issue persistent with kexec-reboot
> > > kernel nowadays.
> > > I am not familiar with TPM and have no clear idea for the time being.
> > > (emulating Platform Configuration Registers ?).  But since this
> > > emulator is held inside a linux kernel image, and the UKI's signature
> > > is checked during kexec_file_load. All of them are safe from
> > > modification, this security is not an urgent issue.
> >
> > Hmm, I'd really think about this with some priority. The measurement
> > stuff should not be an afterthought, it typically has major
> > implications on how you design your transitions, because measurements
> > of some component always need to happen *before* you pass control to
> > it, otherwise they are pointless.
> >
> 
> OK, I will look into the details of TPM to see how to bail out.

This issue is why I thought a different approach to the UEFI emulator
might be useful:

(1) On "kexec -l" execute the EFI binary inside the kernel as a kthread
until it exits boot services and record all TPM measurements into a
buffer
(2) On "kexec -e" use the kernels tpm driver to actually perform all the
prerecorded measurements.
(3) Transition into a "purgatory" that will
clean up the address space to make sure we get to an identity
mapping.
(4) Return control to the EFI app at the point it exited boot services

Additional advantage is that we have filesystem access during (1) so it's
simple to load additional sidecar files for the UKI.

I have two questions:

1: Does the systemd-stub only perform measurements before exiting boot
services or also afterwards?

2: Is it okay to just go to an identity mapping when boot services are
exited or is the identidy mapping actually required for the entire
execution of the EFI app (I know the UEFI spec calls for this, but I
think it should be possible to clean up the address space in a purgatory)?


I played around with this approach last year and got the start of the
kernels EFI stub executing in a kthread and calling into provided boot
services, but the difficult part is memory allocation and cleaning up
the address space in a purgatory.

> 
> Thanks,
> 
> Pingfan
> 

Kind regards,
Jan