Unified Kernel Image Support

Unified Kernel Image Support

[Yishen Miao]

Hello all,

I am experimenting kexec on my box. It uses systemd-boot as the bootloader and boots from a unified kernel image (objcopy'ed cmdline, kernel, initrdramfs, and microcode updates). As of kexec-tools 2.0.25 and systemd 252.5, when I rum systemctl kexec, it returns the following:


# sudo systemctl kexec
Running /usr/bin/kexec --load "/efi/EFI/Linux/ArchLinux-linux.efi" --append "root=UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"(null)
Cannot determine the file type of /efi/EFI/Linux/ArchLinux-linux.efi

It seems that systemctl successfully identified the UKI from systemd-boot, however, kexec could not recognize it.

Are there any plans to add UKI support to kexec? Your response is greatly appreciated!


Best,
mys_721tx
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Unified Kernel Image Support

[Baoquan He]

On 02/03/23 at 10:46pm, Yishen Miao wrote:
> Hello all,
> 
> I am experimenting kexec on my box. It uses systemd-boot as the bootloader and boots from a unified kernel image (objcopy'ed cmdline, kernel, initrdramfs, and microcode updates). As of kexec-tools 2.0.25 and systemd 252.5, when I rum systemctl kexec, it returns the following:
> 
> 
> # sudo systemctl kexec
> Running /usr/bin/kexec --load "/efi/EFI/Linux/ArchLinux-linux.efi" --append "root=UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"(null)
> Cannot determine the file type of /efi/EFI/Linux/ArchLinux-linux.efi
> 
> It seems that systemctl successfully identified the UKI from systemd-boot, however, kexec could not recognize it.
> 
> Are there any plans to add UKI support to kexec? Your response is greatly appreciated!

My colleageus mentioned UKI recently. We have plan to support it, while
haven't started to work on that.

I have a testing machine at hand right now, just finished teseting
upstream patches. If you have the detailed steps about how to make UKI,
privately or publicly, I can try it now, and see what we can do.

Thanks
Baoquan


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Unified Kernel Image Support

[Philipp Rudo]

Hi,

On Mon, 6 Feb 2023 17:19:33 +0800
Baoquan He <bhe@redhat.com> wrote:

> On 02/03/23 at 10:46pm, Yishen Miao wrote:
> > Hello all,
> > 
> > I am experimenting kexec on my box. It uses systemd-boot as the bootloader and boots from a unified kernel image (objcopy'ed cmdline, kernel, initrdramfs, and microcode updates). As of kexec-tools 2.0.25 and systemd 252.5, when I rum systemctl kexec, it returns the following:
> > 
> > 
> > # sudo systemctl kexec
> > Running /usr/bin/kexec --load "/efi/EFI/Linux/ArchLinux-linux.efi" --append "root=UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"(null)
> > Cannot determine the file type of /efi/EFI/Linux/ArchLinux-linux.efi
> > 
> > It seems that systemctl successfully identified the UKI from systemd-boot, however, kexec could not recognize it.
> > 
> > Are there any plans to add UKI support to kexec? Your response is greatly appreciated!  
> 
> My colleageus mentioned UKI recently. We have plan to support it, while
> haven't started to work on that.

I've looked into UKI recently. In order to provide some base support
one should only need to teach kexec_file_load the new file format [1].
However that still leaves two fundamental issues which limit the
usefulness of that support.

1) The way I understand it the initrd contained in the UKI is only a
stub that is supposed to read further "modules" from disk which
together form the initrd needed for the given hardware/system
configuration. The problem is that the kexec_file_load syscall only
accepts one fd for the kernel and one fd for the initrd. So to support
multiple modules we would either need to introduce a new syscall or
define a uABI that allows to pass multiple initrds via this one fd.
Either way it's a new user interface and should be designed with care.

2) As the kernel command line is part of the UKI and is protected by
the signature it cannot be changed by users. So to support kdump with a
UKI a distro would need to find one crashkernel= parameter that works
for all users which is impossible. Thus before kdump can be supported
with UKI there needs to be a  mechanism in place that allows users to
edit the command line. Others have the same problem. There is an open
issue on github [2] to add this support.

So all in all I believe there will be kexec support for UKI but I don't
see it to come anytime soon.

Thanks
Philipp

[1] ...and kexec-tools if you like to support kexec_load. But as the
main use case for UKI is together with Secure Boot I don't think that's
necessary.

[2] https://github.com/systemd/systemd/issues/24539

> I have a testing machine at hand right now, just finished teseting
> upstream patches. If you have the detailed steps about how to make UKI,
> privately or publicly, I can try it now, and see what we can do.


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Unified Kernel Image Support

[Yishen Miao]

Hi Baoquan and Philipp,

I did some digging and the UKI spec seems to suggest the .initrd section is the complete cpio image. [1]

The following commands should make a usable UKI. [2]

$ cat esp/cpu_manufacturer-ucode.img esp/initramfs-linux.img > /tmp/combined_initrd.img
$ osrel_offs=$(objdump -h "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" | awk 'NF==7 {size=strtonum("0x"$3); offset=strtonum("0x"$4)} END {print size + offset}')
$ cmdline_offs=$((osrel_offs + $(stat -Lc%s "/usr/lib/os-release")))
$ splash_offs=$((cmdline_offs + $(stat -Lc%s "/etc/kernel/cmdline")))
$ linux_offs=$((splash_offs + $(stat -Lc%s "/usr/share/systemd/bootctl/splash-arch.bmp")))
$ initrd_offs=$((linux_offs + $(stat -Lc%s "vmlinuz-file")))
$ objcopy \
--add-section .osrel="/usr/lib/os-release" --change-section-vma .osrel=$(printf 0x%x $osrel_offs) \
--add-section .cmdline="/etc/kernel/cmdline" \
--change-section-vma .cmdline=$(printf 0x%x $cmdline_offs) \
--add-section .splash="/usr/share/systemd/bootctl/splash-arch.bmp" \
--change-section-vma .splash=$(printf 0x%x $splash_offs) \
--add-section .linux="vmlinuz-file" \
--change-section-vma .linux=$(printf 0x%x $linux_offs) \
--add-section .initrd="/tmp/combined_initrd.img" \
--change-section-vma .initrd=$(printf 0x%x $initrd_offs) \
"/usr/lib/systemd/boot/efi/linuxx64.efi.stub" "linux.efi"

While the .cmdline section in a UKI cannot be changed per se, it is relative simple to generate a new image with the updated .cmdline. If the user is signing their own binaries for Secure Boot, this should allow them to edit the .cmdline in a roundabout way.

Hope these helps!

Best,
mys_721tx

[1] https://uapi-group.org/specifications/specs/unified_kernel_image/
[2] https://wiki.archlinux.org/title/Unified_kernel_image



> On Feb 6, 2023, at 08:33, Philipp Rudo <prudo@redhat.com> wrote:
> 
> Hi,
> 
> On Mon, 6 Feb 2023 17:19:33 +0800
> Baoquan He <bhe@redhat.com> wrote:
> 
>> On 02/03/23 at 10:46pm, Yishen Miao wrote:
>>> Hello all,
>>> 
>>> I am experimenting kexec on my box. It uses systemd-boot as the bootloader and boots from a unified kernel image (objcopy'ed cmdline, kernel, initrdramfs, and microcode updates). As of kexec-tools 2.0.25 and systemd 252.5, when I rum systemctl kexec, it returns the following:
>>> 
>>> 
>>> # sudo systemctl kexec
>>> Running /usr/bin/kexec --load "/efi/EFI/Linux/ArchLinux-linux.efi" --append "root=UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"(null)
>>> Cannot determine the file type of /efi/EFI/Linux/ArchLinux-linux.efi
>>> 
>>> It seems that systemctl successfully identified the UKI from systemd-boot, however, kexec could not recognize it.
>>> 
>>> Are there any plans to add UKI support to kexec? Your response is greatly appreciated!  
>> 
>> My colleageus mentioned UKI recently. We have plan to support it, while
>> haven't started to work on that.
> 
> I've looked into UKI recently. In order to provide some base support
> one should only need to teach kexec_file_load the new file format [1].
> However that still leaves two fundamental issues which limit the
> usefulness of that support.
> 
> 1) The way I understand it the initrd contained in the UKI is only a
> stub that is supposed to read further "modules" from disk which
> together form the initrd needed for the given hardware/system
> configuration. The problem is that the kexec_file_load syscall only
> accepts one fd for the kernel and one fd for the initrd. So to support
> multiple modules we would either need to introduce a new syscall or
> define a uABI that allows to pass multiple initrds via this one fd.
> Either way it's a new user interface and should be designed with care.
> 
> 2) As the kernel command line is part of the UKI and is protected by
> the signature it cannot be changed by users. So to support kdump with a
> UKI a distro would need to find one crashkernel= parameter that works
> for all users which is impossible. Thus before kdump can be supported
> with UKI there needs to be a  mechanism in place that allows users to
> edit the command line. Others have the same problem. There is an open
> issue on github [2] to add this support.
> 
> So all in all I believe there will be kexec support for UKI but I don't
> see it to come anytime soon.
> 
> Thanks
> Philipp
> 
> [1] ...and kexec-tools if you like to support kexec_load. But as the
> main use case for UKI is together with Secure Boot I don't think that's
> necessary.
> 
> [2] https://github.com/systemd/systemd/issues/24539
> 
>> I have a testing machine at hand right now, just finished teseting
>> upstream patches. If you have the detailed steps about how to make UKI,
>> privately or publicly, I can try it now, and see what we can do.
> 


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Unified Kernel Image Support

[Yishen Miao]

Looks like kexec_file_load got UKI support in September 2023 <https://lore.kernel.org/kexec/20230911052535.335770-1-kernel@jfarr.cc/T/> and kexec-tools also received UKI support on x86_64 recently <https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=0475ec5d32469a486713f9ed7023645bbbbb8769>. Hopefully we will have full UKI support by kexec-tools 2.0.31.

Best,
mys_721tx

> On Feb 6, 2023, at 09:45, Yishen Miao <mys721tx@gmail.com> wrote:
> 
> Hi Baoquan and Philipp,
> 
> I did some digging and the UKI spec seems to suggest the .initrd section is the complete cpio image. [1]
> 
> The following commands should make a usable UKI. [2]
> 
> $ cat esp/cpu_manufacturer-ucode.img esp/initramfs-linux.img > /tmp/combined_initrd.img
> $ osrel_offs=$(objdump -h "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" | awk 'NF==7 {size=strtonum("0x"$3); offset=strtonum("0x"$4)} END {print size + offset}')
> $ cmdline_offs=$((osrel_offs + $(stat -Lc%s "/usr/lib/os-release")))
> $ splash_offs=$((cmdline_offs + $(stat -Lc%s "/etc/kernel/cmdline")))
> $ linux_offs=$((splash_offs + $(stat -Lc%s "/usr/share/systemd/bootctl/splash-arch.bmp")))
> $ initrd_offs=$((linux_offs + $(stat -Lc%s "vmlinuz-file")))
> $ objcopy \
> --add-section .osrel="/usr/lib/os-release" --change-section-vma .osrel=$(printf 0x%x $osrel_offs) \
> --add-section .cmdline="/etc/kernel/cmdline" \
> --change-section-vma .cmdline=$(printf 0x%x $cmdline_offs) \
> --add-section .splash="/usr/share/systemd/bootctl/splash-arch.bmp" \
> --change-section-vma .splash=$(printf 0x%x $splash_offs) \
> --add-section .linux="vmlinuz-file" \
> --change-section-vma .linux=$(printf 0x%x $linux_offs) \
> --add-section .initrd="/tmp/combined_initrd.img" \
> --change-section-vma .initrd=$(printf 0x%x $initrd_offs) \
> "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" "linux.efi"
> 
> While the .cmdline section in a UKI cannot be changed per se, it is relative simple to generate a new image with the updated .cmdline. If the user is signing their own binaries for Secure Boot, this should allow them to edit the .cmdline in a roundabout way.
> 
> Hope these helps!
> 
> Best,
> mys_721tx
> 
> [1] https://uapi-group.org/specifications/specs/unified_kernel_image/
> [2] https://wiki.archlinux.org/title/Unified_kernel_image
> 
> 
> 
>> On Feb 6, 2023, at 08:33, Philipp Rudo <prudo@redhat.com> wrote:
>> 
>> Hi,
>> 
>> On Mon, 6 Feb 2023 17:19:33 +0800
>> Baoquan He <bhe@redhat.com> wrote:
>> 
>>> On 02/03/23 at 10:46pm, Yishen Miao wrote:
>>>> Hello all,
>>>> 
>>>> I am experimenting kexec on my box. It uses systemd-boot as the bootloader and boots from a unified kernel image (objcopy'ed cmdline, kernel, initrdramfs, and microcode updates). As of kexec-tools 2.0.25 and systemd 252.5, when I rum systemctl kexec, it returns the following:
>>>> 
>>>> 
>>>> # sudo systemctl kexec
>>>> Running /usr/bin/kexec --load "/efi/EFI/Linux/ArchLinux-linux.efi" --append "root=UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"(null)
>>>> Cannot determine the file type of /efi/EFI/Linux/ArchLinux-linux.efi
>>>> 
>>>> It seems that systemctl successfully identified the UKI from systemd-boot, however, kexec could not recognize it.
>>>> 
>>>> Are there any plans to add UKI support to kexec? Your response is greatly appreciated!  
>>> 
>>> My colleageus mentioned UKI recently. We have plan to support it, while
>>> haven't started to work on that.
>> 
>> I've looked into UKI recently. In order to provide some base support
>> one should only need to teach kexec_file_load the new file format [1].
>> However that still leaves two fundamental issues which limit the
>> usefulness of that support.
>> 
>> 1) The way I understand it the initrd contained in the UKI is only a
>> stub that is supposed to read further "modules" from disk which
>> together form the initrd needed for the given hardware/system
>> configuration. The problem is that the kexec_file_load syscall only
>> accepts one fd for the kernel and one fd for the initrd. So to support
>> multiple modules we would either need to introduce a new syscall or
>> define a uABI that allows to pass multiple initrds via this one fd.
>> Either way it's a new user interface and should be designed with care.
>> 
>> 2) As the kernel command line is part of the UKI and is protected by
>> the signature it cannot be changed by users. So to support kdump with a
>> UKI a distro would need to find one crashkernel= parameter that works
>> for all users which is impossible. Thus before kdump can be supported
>> with UKI there needs to be a  mechanism in place that allows users to
>> edit the command line. Others have the same problem. There is an open
>> issue on github [2] to add this support.
>> 
>> So all in all I believe there will be kexec support for UKI but I don't
>> see it to come anytime soon.
>> 
>> Thanks
>> Philipp
>> 
>> [1] ...and kexec-tools if you like to support kexec_load. But as the
>> main use case for UKI is together with Secure Boot I don't think that's
>> necessary.
>> 
>> [2] https://github.com/systemd/systemd/issues/24539
>> 
>>> I have a testing machine at hand right now, just finished teseting
>>> upstream patches. If you have the detailed steps about how to make UKI,
>>> privately or publicly, I can try it now, and see what we can do.
>> 
>