2023-09-12 11:44:30

by Jarkko Sakkinen

[permalink] [raw]
Subject: Re: [PATCH 0/1] x86/kexec: UKI support

On Tue Sep 12, 2023 at 1:54 AM EEST, Jan Hendrik Farr wrote:
> > What the heck is UKI?
>
> UKI (Unified Kernel Image) is the kernel image + initrd + cmdline (+
> some other optional stuff) all packaged up together as one EFI
> application.
>
> This EFI application can then be launched directly by the UEFI without
> the need for any additional stuff (or by systemd-boot). It's all self
> contained. One benefit is that this is a convenient way to distribute
> kernels all in one file. Another benefit is that the whole combination
> of kernel image, initrd, and cmdline can all be signed together so
> only that particular combination can be executed if you are using
> secure boot.

Is this also for generic purpose distributions? I mean it is not
uncommon having to tweak the command-line in a workstation.

> The format itself is rather simple. It's just a PE file (as required
> by the UEFI spec) that contains a small stub application in the .text,
> .data, etc sections that is responsible for invoking the contained
> kernel and initrd with the contained cmdline. The kernel image is
> placed into a .kernel section, the initrd into a .initrd section, and
> the cmdline into a .cmdline section in the PE executable.

How does this interact with the existing EFI stub support in linux?

> If we want to kexec a UKI we could obviously just have userspace pick
> it apart and kexec it like normal. However in lockdown mode this will
> only work if you sign the kernel image that is contained inside the
> UKI. The problem with that is that anybody can then grab that signed
> kernel and launch it with any initrd or cmdline. So instead this patch
> makes the kernel do the work instead. The kernel verifies the
> signature on the entire UKI and then passes its components on to the
> normal kexec bzimage loader.
>
> Useful Links:
> UKI format documentation: https://uapi-group.org/specifications/specs/unified_kernel_image/
> Arch wiki: https://wiki.archlinux.org/title/Unified_kernel_image
> Fedora UKI support: https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1

BR, Jarkko


2023-09-12 21:40:10

by Jan Hendrik Farr

[permalink] [raw]
Subject: Re: [PATCH 0/1] x86/kexec: UKI support



On Tue, Sep 12, 2023, at 12:33 PM, Jarkko Sakkinen wrote:
> On Tue Sep 12, 2023 at 1:54 AM EEST, Jan Hendrik Farr wrote:
>> > What the heck is UKI?
>>
>> UKI (Unified Kernel Image) is the kernel image + initrd + cmdline (+
>> some other optional stuff) all packaged up together as one EFI
>> application.
>>
>> This EFI application can then be launched directly by the UEFI without
>> the need for any additional stuff (or by systemd-boot). It's all self
>> contained. One benefit is that this is a convenient way to distribute
>> kernels all in one file. Another benefit is that the whole combination
>> of kernel image, initrd, and cmdline can all be signed together so
>> only that particular combination can be executed if you are using
>> secure boot.
>
> Is this also for generic purpose distributions? I mean it is not
> uncommon having to tweak the command-line in a workstation.

This is for generic purpose distributions. See fedora's planned rollout: https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
Or Arch: https://wiki.archlinux.org/title/Unified_kernel_image

There are UKI addons that help you achieve this. These are additional PE files that contain for example additional cmdline parameters. On a generic Linux distro doing secure boot you'd generally use shim, could enroll MOK and use that to sign an addon for your machine.

This patch currently does not support addons. The plan would be to support them in the future though.

I personally always run my own compiled kernel and build a UKI from that so I can obviously tweak the cmdline that way and sign the UKI with my own secure boot key.

>> The format itself is rather simple. It's just a PE file (as required
>> by the UEFI spec) that contains a small stub application in the .text,
>> .data, etc sections that is responsible for invoking the contained
>> kernel and initrd with the contained cmdline. The kernel image is
>> placed into a .kernel section, the initrd into a .initrd section, and
>> the cmdline into a .cmdline section in the PE executable.
>
> How does this interact with the existing EFI stub support in linux?

It doesn't. During normal boot of a UKI the stub in it is used (systemd-stub, see: https://www.freedesktop.org/software/systemd/man/systemd-stub.html). The kernel's own EFI stub will still be in the binary inside the .linux section but not used.

Now in this patch (also see v2 I already posted) obviously non of the stubs are used.

2023-09-14 09:03:13

by Lennart Poettering

[permalink] [raw]
Subject: Re: [PATCH 0/1] x86/kexec: UKI support

On Di, 12.09.23 17:32, Jan Hendrik Farr ([email protected]) wrote:

> >> The format itself is rather simple. It's just a PE file (as required
> >> by the UEFI spec) that contains a small stub application in the .text,
> >> .data, etc sections that is responsible for invoking the contained
> >> kernel and initrd with the contained cmdline. The kernel image is
> >> placed into a .kernel section, the initrd into a .initrd section, and
> >> the cmdline into a .cmdline section in the PE executable.
> >
> > How does this interact with the existing EFI stub support in
> > linux?
>
> It doesn't. During normal boot of a UKI the stub in it is used
> (systemd-stub, see:
> https://www.freedesktop.org/software/systemd/man/systemd-stub.html). The
> kernel's own EFI stub will still be in the binary inside the .linux
> section but not used.

That's not true actually, if the inner kernel supports the EFI stub
then systemd-stub actually defers to that for kernel execution. It's
more portable that way, since the kernel then deals with the
differences in the boot protocol on different architectures.

Lennart

--
Lennart Poettering, Berlin

2023-09-14 12:06:53

by Jarkko Sakkinen

[permalink] [raw]
Subject: Re: [PATCH 0/1] x86/kexec: UKI support

On Thu Sep 14, 2023 at 11:48 AM EEST, Lennart Poettering wrote:
> On Di, 12.09.23 17:32, Jan Hendrik Farr ([email protected]) wrote:
>
> > >> The format itself is rather simple. It's just a PE file (as required
> > >> by the UEFI spec) that contains a small stub application in the .text,
> > >> .data, etc sections that is responsible for invoking the contained
> > >> kernel and initrd with the contained cmdline. The kernel image is
> > >> placed into a .kernel section, the initrd into a .initrd section, and
> > >> the cmdline into a .cmdline section in the PE executable.
> > >
> > > How does this interact with the existing EFI stub support in
> > > linux?
> >
> > It doesn't. During normal boot of a UKI the stub in it is used
> > (systemd-stub, see:
> > https://www.freedesktop.org/software/systemd/man/systemd-stub.html). The
> > kernel's own EFI stub will still be in the binary inside the .linux
> > section but not used.
>
> That's not true actually, if the inner kernel supports the EFI stub
> then systemd-stub actually defers to that for kernel execution. It's
> more portable that way, since the kernel then deals with the
> differences in the boot protocol on different architectures.

OK, that's nice.

> Lennart
>
> --
> Lennart Poettering, Berlin

BR, Jarkko