Looks like kexec_file_load got UKI support in September 2023 <https://lore.kernel.org/kexec/20230911052535.335770-1-kernel@xxxxxxxx/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@xxxxxxxxx> 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@xxxxxxxxxx> wrote: >> >> Hi, >> >> On Mon, 6 Feb 2023 17:19:33 +0800 >> Baoquan He <bhe@xxxxxxxxxx> 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. >> >
