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.
>
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
