Message-ID: <Zsb1isJ2cYRp2jpj@gardel-login>
Date: Thu, 22 Aug 2024 10:23:38 +0200
From: Lennart Poettering <mzxreary@...inter.de>
To: Pingfan Liu <piliu@...hat.com>
Cc: Ard Biesheuvel <ardb@...nel.org>, Jan Hendrik Farr <kernel@...rr.cc>,
	Philipp Rudo <prudo@...hat.com>,
	Jarkko Sakkinen <jarkko@...nel.org>,
	Eric Biederman <ebiederm@...ssion.com>, Baoquan He <bhe@...hat.com>,
	Dave Young <dyoung@...hat.com>, Mark Rutland <mark.rutland@....com>,
	Will Deacon <will@...nel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	kexec@...ts.infradead.org, linux-efi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFCv2 0/9] UEFI emulator for kexec

On Do, 22.08.24 13:42, Pingfan Liu (piliu@...hat.com) wrote:

 > On Wed, Aug 21, 2024 at 10:27 PM Lennart Poettering
> <mzxreary@...inter.de> wrote:
> >
> > On Mo, 19.08.24 22:53, Pingfan Liu (piliu@...hat.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.

> > 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.

Lennart

--
Lennart Poettering, Berlin

Powered by blists - more mailing lists