From: Lennart Poettering <mzxreary@0pointer.de>
To: Pingfan Liu <piliu@redhat.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
Jan Hendrik Farr <kernel@jfarr.cc>,
Philipp Rudo <prudo@redhat.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
Eric Biederman <ebiederm@xmission.com>,
Baoquan He <bhe@redhat.com>, Dave Young <dyoung@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
kexec@lists.infradead.org, linux-efi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFCv2 0/9] UEFI emulator for kexec
Date: Thu, 22 Aug 2024 10:23:38 +0200 [thread overview]
Message-ID: <Zsb1isJ2cYRp2jpj@gardel-login> (raw)
In-Reply-To: <CAF+s44S2Ph1_nFcZYy3j0Jr4yuHayb5zdNu1YXg8ce_Lf3TOgQ@mail.gmail.com>
On Do, 22.08.24 13:42, Pingfan Liu (piliu@redhat.com) wrote:
> On Wed, Aug 21, 2024 at 10:27 PM Lennart Poettering
> <mzxreary@0pointer.de> wrote:
> >
> > On Mo, 19.08.24 22:53, Pingfan Liu (piliu@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.
> > 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
next prev parent reply other threads:[~2024-08-22 8:23 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-19 14:53 [RFCv2 0/9] UEFI emulator for kexec Pingfan Liu
2024-08-19 14:53 ` [RFCv2 1/9] efi/libstub: Ask efi_random_alloc() to skip unusable memory Pingfan Liu
2024-08-19 18:00 ` Jarkko Sakkinen
2024-08-20 0:58 ` Pingfan Liu
2024-08-28 13:28 ` Ard Biesheuvel
2024-08-19 14:53 ` [RFCv2 2/9] efi/libstub: Complete efi_simple_text_output_protocol Pingfan Liu
2024-08-19 14:53 ` [RFCv2 3/9] efi/emulator: Initial rountines to emulate EFI boot time service Pingfan Liu
2024-08-19 14:53 ` [RFCv2 4/9] efi/emulator: Turn on mmu for arm64 Pingfan Liu
2024-08-19 14:53 ` [RFCv2 5/9] kexec: Introduce kexec_pe_image to parse and load PE file Pingfan Liu
2024-08-19 14:53 ` [RFCv2 6/9] arm64: kexec: Introduce a new member param_mem to kimage_arch Pingfan Liu
2024-08-19 14:53 ` [RFCv2 7/9] arm64: mm: Change to prototype of Pingfan Liu
2024-08-19 14:53 ` [RFCv2 8/9] arm64: kexec: Prepare page table for emulator Pingfan Liu
2024-08-19 14:53 ` [RFCv2 9/9] arm64: kexec: Enable kexec_pe_image Pingfan Liu
2024-08-21 14:27 ` [RFCv2 0/9] UEFI emulator for kexec Lennart Poettering
2024-08-22 5:42 ` Pingfan Liu
2024-08-22 6:16 ` Dave Young
2024-08-22 10:51 ` Pingfan Liu
2024-08-22 11:54 ` Dave Young
2024-08-22 10:56 ` Jan Hendrik Farr
2024-08-22 12:04 ` Dave Young
2024-08-22 8:23 ` Lennart Poettering [this message]
2024-08-22 10:45 ` Pingfan Liu
2024-08-22 11:42 ` Jan Hendrik Farr
2024-08-22 11:45 ` Lennart Poettering
2024-08-22 14:29 ` Pingfan Liu
2024-08-26 13:39 ` Lennart Poettering
2024-09-09 13:38 ` Pingfan Liu
2024-09-10 7:06 ` Lennart Poettering
2024-08-28 17:08 ` Ard Biesheuvel
2024-09-02 5:40 ` Pingfan Liu
2024-09-06 10:54 ` Philipp Rudo
2024-09-07 11:27 ` Jarkko Sakkinen
2024-09-07 11:31 ` Jarkko Sakkinen
2024-09-07 11:41 ` Jarkko Sakkinen
2024-09-09 13:55 ` Philipp Rudo
2024-09-09 17:09 ` Jarkko Sakkinen
2024-09-09 9:48 ` Lennart Poettering
2024-09-09 10:42 ` Jan Hendrik Farr
2024-09-09 13:49 ` Philipp Rudo
2024-09-09 14:04 ` Ard Biesheuvel
2024-09-09 14:37 ` Jan Hendrik Farr
2024-09-10 7:54 ` Lennart Poettering
2024-10-08 11:59 ` Pingfan Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zsb1isJ2cYRp2jpj@gardel-login \
--to=mzxreary@0pointer.de \
--cc=ardb@kernel.org \
--cc=bhe@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=jarkko@kernel.org \
--cc=kernel@jfarr.cc \
--cc=kexec@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=piliu@redhat.com \
--cc=prudo@redhat.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox