From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Dimitri John Ledkov" <dimitri.ledkov@canonical.com>
Cc: "Neal Gompa" <ngompa13@gmail.com>,
<systemd-devel@lists.freedesktop.org>, <x86@kernel.org>,
<kexec@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
<dhowells@redhat.com>, <keyrings@vger.kernel.org>,
<bhelgaas@google.com>, "Jan Hendrik Farr" <kernel@jfarr.cc>,
<tglx@linutronix.de>, <akpm@linux-foundation.org>,
<bluca@debian.org>
Subject: Re: [systemd-devel] [PATCH 0/1] x86/kexec: UKI support
Date: Mon, 25 Sep 2023 19:43:38 +0300 [thread overview]
Message-ID: <CVS5DQME8XMT.2DEPELDXBPGIX@suppilovahvero> (raw)
In-Reply-To: <CADWks+bRm9LnujBo1SiATDfC1sCNU0vvCy_r=YBpYLXcQrbQeA@mail.gmail.com>
On Mon Sep 18, 2023 at 6:41 PM EEST, Dimitri John Ledkov wrote:
> On Tue, 12 Sept 2023 at 11:38, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Tue Sep 12, 2023 at 2:20 AM EEST, Neal Gompa wrote: > On Mon, Sep 11, 2023 at 7:15 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > On Sat Sep 9, 2023 at 7:18 PM EEST, Jan Hendrik Farr wrote:
> > > > > Hello,
> > > > >
> > > > > this patch implements UKI support for kexec_file_load. It will require support
> > > > > in the kexec-tools userspace utility. For testing purposes the following can be used:
> > > > > https://github.com/Cydox/kexec-test/
> > > > >
> > > > > There has been discussion on this topic in an issue on GitHub that is linked below
> > > > > for reference.
> > > > >
> > > > >
> > > > > Some links:
> > > > > - Related discussion: https://github.com/systemd/systemd/issues/28538
> > > > > - Documentation of UKIs: https://uapi-group.org/specifications/specs/unified_kernel_image/
> > > > >
> > > > > Jan Hendrik Farr (1):
> > > > > x86/kexec: UKI support
> > > > >
> > > > > arch/x86/include/asm/kexec-uki.h | 7 ++
> > > > > arch/x86/include/asm/parse_pefile.h | 32 +++++++
> > > > > arch/x86/kernel/Makefile | 2 +
> > > > > arch/x86/kernel/kexec-uki.c | 113 +++++++++++++++++++++++++
> > > > > arch/x86/kernel/machine_kexec_64.c | 2 +
> > > > > arch/x86/kernel/parse_pefile.c | 110 ++++++++++++++++++++++++
> > > > > crypto/asymmetric_keys/mscode_parser.c | 2 +-
> > > > > crypto/asymmetric_keys/verify_pefile.c | 110 +++---------------------
> > > > > crypto/asymmetric_keys/verify_pefile.h | 16 ----
> > > > > 9 files changed, 278 insertions(+), 116 deletions(-)
> > > > > create mode 100644 arch/x86/include/asm/kexec-uki.h
> > > > > create mode 100644 arch/x86/include/asm/parse_pefile.h
> > > > > create mode 100644 arch/x86/kernel/kexec-uki.c
> > > > > create mode 100644 arch/x86/kernel/parse_pefile.c
> > > > >
> > > > > --
> > > > > 2.40.1
> > > >
> > > > What the heck is UKI?
> > >
> > > Unified Kernel Images. More details available here:
> > > https://uapi-group.org/specifications/specs/unified_kernel_image/
> > >
> > > It's a way of creating initramfs-style images as fully generic,
> > > reproducible images that can be built server-side.
> >
> > You can build today a kernel with these compiled in:
> >
> > 1. EFI stub
> > 2. initeramfs
> > 3. cmdline
> >
> > Why another way (and label 'UKI') for a pre-existing feature?
> >
>
> In Ubuntu, we have considered to use the existing kernel features
> before going off to use UKI. Here are some of the reasons why we
> didn't opt to use the kernel builtin things:
> 1) we wanted to have ability to have TPM measured kernel commandline
> performed before kernel is being executed, which is what sd-stub
> provides us
OK this does make a lot of sense.
> 2) we wanted to have ability to update / regenerate initrd, without
> rebuilding kernel. Thus whenever userspace in the initrd needs
> updating, we can generate new initrd for existing kernel build, create
> new kernel.efi, whilst using existing .linux / vmlinuz build. I don't
> believe it is currently trivial to relink vmlinuz with builtin initrd.
> 3) licensing wise it was not clear if initrd has to be GPLv2
> compatible when linked inside vmlinuz, or if it can contain GPLv3 /
> LGPLv3 userspace code - with UKI it is believed unambigiously true,
> because vmlinuz boots by itself standalone and is compiled separately
> of the UKI.
Right UKI wraps kernel and kernel is a "leaf object".
> 4) we wanted to have ability to override cmdline via kernel args
> without secureboot, and use stock cmdline args under secureboot, to
> allow debugging & production behaviour from a single signed kernel.efi
> (that was custom development, and could be done in the stock vmlinuz
> too).
> 5) obvious mention, the intention here is to have TPM PCR measurements
> and Secureboot signature for vmlinuz and initrd and cmdline and dtb.
> There is otherwise no support for standalone signed initrd, cmdline,
> dtb today. Nor does vendoring it into vmlinuz achieves this to the
> same extent (and ease of predicting for sealing / resealing purposes).
ok
> 6) in Ubuntu kernel.efi also has sbat section for targeted revocations
> (discussed separately elsewhere)
>
> Overall, it is mostly about flexibility to be able to reuse the same
> initrd against multiple kernel builds, or update use multiple initrd
> against the same kernel build. This is imho the biggest issue with
> using initrd built-into the vmlinuz itself.
> Resource wise, the initrd passed in via kernel.efi can be freed, as
> far as I understand. I don't know if the one built-into the vmlinuz is
> freeable.
>
> Improving design to do something else instead of UKI would be
> welcomed. Or for example improving the zimg linus upstream format to
> be a partial or a valid UKI would help as well. For example, building
> the kernel built-in initrd as a .initrd section that is replacable
> would be nice, or allowing to preload zimg with .dtb or .cmdline
> sections would help, and appropriately improve the linux efi stab to
> do measurements and loading of .dtb / .initrd from itself would be
> nice. Because then all the benefits / requirements described above
> could be made available out of the box and be trivially updatable. The
> biggest one being splitting out things into sections that can be
> updated with objcopy.
BR, Jarkko
prev parent reply other threads:[~2023-09-25 16:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-09 16:18 [PATCH 0/1] x86/kexec: UKI support Jan Hendrik Farr
2023-09-09 16:18 ` [PATCH 1/1] " Jan Hendrik Farr
2023-09-09 17:15 ` [PATCH 0/1] " Luca Boccassi
2023-09-09 17:57 ` Jan Hendrik Farr
2023-09-09 18:10 ` Luca Boccassi
2023-09-11 3:23 ` Jan Hendrik Farr
2023-09-11 22:02 ` Jarkko Sakkinen
2023-09-11 22:54 ` Jan Hendrik Farr
2023-09-12 10:33 ` Jarkko Sakkinen
2023-09-12 15:32 ` Jan Hendrik Farr
2023-09-12 17:41 ` Jarkko Sakkinen
2023-09-12 18:56 ` Jan Hendrik Farr
2023-09-12 19:24 ` Jarkko Sakkinen
2023-09-12 19:38 ` Jan Hendrik Farr
2023-09-12 20:49 ` Jan Hendrik Farr
2023-09-13 14:45 ` Jarkko Sakkinen
2023-09-13 15:07 ` Jan Hendrik Farr
2023-09-13 15:58 ` Jarkko Sakkinen
2023-09-14 9:11 ` Lennart Poettering
2023-09-14 12:12 ` Jarkko Sakkinen
2023-09-14 8:48 ` Lennart Poettering
2023-09-14 11:52 ` Jarkko Sakkinen
2023-09-11 23:20 ` [systemd-devel] " Neal Gompa
2023-09-12 10:37 ` Jarkko Sakkinen
2023-09-18 15:41 ` Dimitri John Ledkov
2023-09-25 16:43 ` Jarkko Sakkinen [this message]
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=CVS5DQME8XMT.2DEPELDXBPGIX@suppilovahvero \
--to=jarkko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bhelgaas@google.com \
--cc=bluca@debian.org \
--cc=dhowells@redhat.com \
--cc=dimitri.ledkov@canonical.com \
--cc=kernel@jfarr.cc \
--cc=kexec@lists.infradead.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ngompa13@gmail.com \
--cc=systemd-devel@lists.freedesktop.org \
--cc=tglx@linutronix.de \
--cc=x86@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).