andreyv/sbupdate

Generate and sign kernel images for UEFI Secure Boot on Arch Linux

sbupdate's Issues

Updating DKMS modules in initramfs doesn't trigger update

If a DKMS module is included in the initramfs (via MODULES= in mkinitcpio.conf) and the DKMS module is update, sbupdate hooks are not triggered. Here is an example scenario:

• nvidia-dkms is installed
• mkinitcpio.conf contains MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)
• sbupdate is installed and configured

When nvidia-dkms is updated to a newer version, pacman automatically runs dkms install followed by mkinitcpio. However, sbupdate is not run (this can be verified by observing that the signed EFI file is older than the initramfs).

vmlinuz-linux-zen no longer fits into allocated section space

Hi,

I am using Archlinux with ZEN kernel (5.8.8-zen1-1-zen) on 2 of the physical machines and my VirtualBox images at home. I only use sbupdate on my Dell XPS laptop, and for other ones I have build my own UEFI boot image based on sbuupdate code, but without image signing.

And after upgrading to 5.8 release of the kernel all my physical machines started having very different boot problems.

It took me months to figure out the root cause. Looks like the "/boot/vmlinuz-linux-zen" image is not fitting into ".linux" section allocated between "--change-section-vma .linux=0x2000000" and "-change-section-vma .initrd=0x3000000". The image itself is 9458592 (decimal) bytes but for some reason it does not fit into 0x1000000 (assuming this is hexadecimal) bytes allocated.

I am not an expert here what is the right solution, but I have modified a section of the sbupdate that fixed the issue for me:

  objcopy \
    --add-section .osrel="/etc/os-release"                          --change-section-vma .osrel=0x20000    \
    --add-section .cmdline=<(echo -n "${cmdline}")                  --change-section-vma .cmdline=0x30000  \
    --add-section .linux="$2"                                       --change-section-vma .linux=0x40000    \
    --add-section .initrd=<(cat "${INITRD_PREPEND[@]}" "${initrd}") --change-section-vma .initrd=0x2000000 \
    "${EFISTUB}" "${output}"

Note that I am not using ".splash" section, because that gives me a smoothest transition from the Dell logo. Before I was just specifying "/dev/null" as an image and that worked the same.

Kernel parameters in the initramfs?

If the initramfs has embedded parameters (I'm planning to do this with dracut); will the unified image retain those parameters without specifying them again in the sbupdate.conf ? I looked through the script; but could not gather an answer on my own.

sbsign warning of gaps between PE/COFF sections

I have noticed that whenever I use sbupdate to sign the .efi generated, it gives two warning:

warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?
warning: data remaining[26413568 vs 26423184]: gaps between PE/COFF sections?

I can't find much information about it online, but it appears to be an issue with sbsign. It seems to resulting in an unbootable image.

Manjaro compatibility

Hello and thank you for your tool.

0ad2b48 changes have broken compatibility with Manjaro.
Precisely, Manjaro uses kernelbase for naming its kernels inside /boot instead of pkgbase, but falls back to the latter in order to be compatible with kernels from Arch repos.
So now sbupdate fails to find a kernel ($1) in /boot because it looks for another name.
The difference is as follows:
kernelbase is like 5.4-x86_64, and files located in /boot are named like vmlinuz-5.4-x86_64, initramfs-5.4-x86_64 and so on.
pkgbase is like linux54, that's what new version of sbupdate looks for and fails to find.

Images generated by the previous version were named like 5.4-x86_64-signed.efi.

Here are some files that could be of help. I hope you'll find a way to resolve this.
Thank you in advance!

(etc)(mkinitcpio.d)(linux54.preset).txt
(usr)(share)(libalpm)(scripts)(mkinitcpio-install).txt
(usr)(lib)(modules)(5.4.0-1-MANJARO).zip

Testing

Forgive my ignorance, I've just managed to boot my first unified kernel image.
I found this repo from this page and I am wondering if there should be a trigger for downgrades. I'm not sure how Operation = Upgrade works when Target= is a file.

Regarding Add tests (how?), how can I contact you? I've been working on an ansible playbook to configure the installation process. I might be able to work something out using btrfs snapshots, combined with timeshift-autosnap. There's also grub-btrfs, which creates new grub entries for snapshots. There may be a way to modify it and create new Grub entries for new images.

[Feature Request] Please add an option to sign already created image

mkinitcpio and dracut can create Unified kernel images without 3rd party tools
https://wiki.archlinux.org/title/Unified_kernel_image#Preparing_a_unified_kernel_image
This tool does the same which is redundant.
Can you add an option to bypass the creation of the image and just sign the created file which is located in a specified path?

Missing AUR keys

Hi. With my dual-boot windows/archlinux machine I'm having to look into dealing with secure boot (with imminent windows 11 release almost upon us requiring secure boot) which has led me here to sbupdate. I'm having trouble installing sbupdate however.....
Trying to install this via Pamac GUI ends with "sbupdate git repo ... FAILED (unknown public key F6532C30466E8B3E)
==> ERROR: One or more PGP signatures could not be verified! Failed to build sbupdate-git"
Digging around on the net gave a few work around hints which I tried as follows. First I tried at the CLI : "curl https://github.com/andreyv.gpg | gpg --import" which returned : "gpg: key F6532C30466E8B3E: 2 signatures not checked due to missing keys". I then also tried "gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys F6532C30466E8B3E | gpg --import" which gave:
gpg: key F6532C30466E8B3E: "Andrey Vihrov [email protected]"
gpg: Total number processed: 1
gpg: unchanged: 1
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

All of these attempts seem to point to one thing - missing keys which seems to be a showstopper for building and installing. Can anyone help? Cheers.

EXTRA_SIGN in combination w/ e.g. sd-boot can lead to an attacker being able to sign a malicious file

I was just made aware that EXTRA_SIGN allows for the following attack scenario, with the example given in the README:

EXTRA_SIGN=('/boot/EFI/BOOT/BOOTX64.EFI' '/boot/EFI/systemd/systemd-bootx64.efi')

Suppose you boot via systemd-bootx64.efi.

1. The attacker can easily control BOOTX64.EFI as well as systemd-bootx64.efi. Suppose they maliciously modify the former file (i.e., the one you dont boot from).
2. The user boots using the latter file and updates the system, a Linux kernel update is pulled in and sbupdate automatically signs both files, the attacker now has hold of a signed but malicious bootloader.
3. The attacker copies BOOTX64.EFI to systemd-bootx64.efi and has now control over the bootloader.

I think there are two solutions which, at best, could be combined:

1. Don't let the attacker control (possibly) unsigned files, i.e. allow for EXTRA_FILES to support input as well as output (say, pull in the file from /usr/lib/systemd/boot/efi/systemd-bootx64.efi).
2. Only sign those files you actually booted from, put a warning into the README.md and modify the example.

The second adjustment is easily made, but the former guards against further, similar attacks:

If the unsigned kernel files are stored on the ESP as well, say you adhere to XBOOTLDR 1 and have the ESP mounted in /boot, s.t. (by default) ArchLinux initramfs/vmlinuz will be put into /boot/..., the same attack can be carried out in a modified fashion:

1. You boot into kernel A but the attacker modifies kernel A-fallback.
2. sbupdate signs the malicious kernel A-fallback*.

Since sbupdate by default is only run on updates, thus overwriting A-fallback* with A-fallback', this will only work if the user triggers it manually. However, if the user has actually multiple kernels installed, say linux and linux-lts, then this attack is even more likely since:

1. You boot into kernel A but the attacker modified kernel B.
2. An update for kernel A triggers sbupdate hook and the malicious kernel B* is signed.

Now the attacker could use the sd-boot menu to boot the kernel B*

RFE: add `CMDLINE_ALWAYS` or alike for kernel options that are always added

For now, if I manually override cmdline for a kernel using CMDLINE["linux-X"], options in CMDLINE_DEFAULT are not used. However, when it comes to options like root=, defining them again for each kernel is annoying. Thus, it would be nice to add a CMDLINE_ALWAYS setting or alike that contains kernel options always applied to all kernels, cmdline overridden or not.

Output filename for kernel?

In some cases it can be useful.

Feature Request: Create variants of the same kernel

I'd like to build different signed EFI executables based on the same kernel image.
The use case comes from the fact, that I'm directly booting Linux' EFISTUB without any bootloader in between. I'd like to have variants of my linux-signed.efi, that have different commandlines (e.g. to boot into systemd's emergency.target) or different initrds (e.g. without autodetect for broader hardware support). Currently I can only specify a cmdline per linux* package.

[Feature Request] Please add option to add an extra initrd to efi image

Hi there,

I have been using your excellent tool for quite a number of years now and have recently migrated my system to a new laptop. Unfortunately, this one has a small bug in it`s ACPI implementation under Linux (because of course it does), so that I want/need to load a modified ACPI table during boot in order to fix S3sleep. I would therefore like to automagically incorporate this blob into my efi image that sbupdate compiles and signs.

I have provisionally done this by:

1. Adding a new variable to sbupdate.conf - INITRD_EXTRA
2. Adding that new vriable into the objcopy part of sbupdate, by simply adding it in between INITRD_PREPEND and initrd

Do you think, that you might put something like this into the official release?

Thank you for all your work creating and sharing this very helpful piece of software!

signed unified kernel image file name

For each installed Arch kernel, a signed UEFI image will be generated, by default in /boot/EFI/Arch/<NAME>-signed.efi.

Is it possible to redefine the file name? For example, I want to write a signed unified kernel image to <EFI_SYSTEM_PARTITION>\EFI\BOOT\BOOTX64.EFI. This may be specified as an option OUT_FILE[<NAME>] where <NAME> is a kernel name.

use mkinitcpio to build uefi executables

With this archlinux/mkinitcpio#53 mkinitcpio now has support for building uefi executables. It would be ideal is sbupdate used this as well.

objcopy: section below image base

When I upgrade my kernel, I get this warning while it generates the unified kernel image:

Generating and signing linux-signed.efi
objcopy: /efi/EFI/Linux/linux-signed.efi:.osrel: section below image base
objcopy: /efi/EFI/Linux/linux-signed.efi:.cmdline: section below image base
objcopy: /efi/EFI/Linux/linux-signed.efi:.linux: section below image base
objcopy: /efi/EFI/Linux/linux-signed.efi:.initrd: section below image base
Signing Unsigned original image

The UEFI fails to boot to the image.

Multiple cmdlines per kernel

I have a situation where I have a single kernel, but multiple commandlines. Normally I use systemd-boot to do this, but now I want to move to using secureboot with an encrypted /boot partition, and I'm pretty sure systemd-boot isn't able to read anything else than simple vfat partitions.

Right now I set KERNELS from the config as hack to also sign the "second" kernel in /boot, which is simply a symlink to my main kernel. But maybe it's better to add some extra functionality to the script to do this in a more supported way, as FAT partitions don't support symlinks.

Is it possible to enable secureboot without erasing the existing OS?

i use arch os now.And I only have one desktop.
I'm planning to buy a new laptop next year and would like to implement secureboot on it
But I want to try secureboot with my existing OS because I'm buying a dell xps15-like laptop with higher and better specs and I don't want to mess with it and break it.If you can't implement it without wiping the existing OS, is there any way to do it, such as virtualization?

Feature suggestion: Support for seamless boot via ACPI BGRT

Hi,

please allow me to first say how much I love and appreciate what you've done with sbupdate, this tool has really made it so much easier to manage my secure boot process and it's updates!

Now that both i915 in the kernel and plymouth have gotten support for flicker-free booting via ACPI BGRT, the last step for that to really work well in my setup is sbupdate support. Now, I really have no idea how this works, but would it be possible to have sbupdate also support this feature in the same way that plymouth does? That would make my boot process really seamless. And note that this is different from just using a blank splash, because that would be a disruption from UEFI splash to blank screen back to UEFI splash via plymouth.

Thank you!

Question: is btrfs supported with direct booting?

I am interested in moving to btfs, but I am not sure if it was compatible with the direct booting method of sbupdate. The arch wiki article says to "check if your boot loader supports Btrfs."

Does sbupdate's boot images support btrfs? If so, does it also support booting with a specific revision of the root file system somehow?

In my current setup, sbupdate's directly bootable images are on an unencrypted EFI partition, signed by my custom keys (which are loaded into the EFI firmware), with secure boot enabled, which then boots a signed image and using TPM 2 (based on the boot secure boot enabled) automatically unlocks my LUKS2 volumes (which is otherwise a simple LVM_on_LUKS setup).

I am about to get a new laptop, and I thinking of using btrfs for the root file system. I like in my current setup the fact that it is secure, convenient (with the TPM-based automatic unlock, just like BitLocker), and it works like a charm.

Thanks!

suspend to disk (hibernate)

Hello,
hibernation (on encrypted swap partition) used to work fine on my old secureboot-less with grub setup, but won't work anymore since I went to sbupdate with direct boot. I've put the resume line along with the cryptdevice on 'CMDLINE_DEFAULT' on sbupdate.conf.

Does this have anything to do with sbupdate or it's a secure boot thing?

Error when both DB.key/db.key exist

@(DB|db).key will match both and return both, if both exist. This will lead to a failure.
Not sure what's the best way to fix this.

Feature Request: Add prior kernels to dbx

SBUpdate does not currently blacklist prior kernel revisions in the dbx. This means the kernel can be downgraded to older versions that were previously signed. These older versions could possibly have known and reported vulnerabilities which could counter the benefits that secure boot provides. It is a good idea to retain one prior version of the kernel in case there's something wrong with an update, but kernel revision N-2 and older should not be needed again.

Not all users will want this added functionality. In fact, providing this functionality in the the most general cases with a variety of bootloaders and multiple OSes would be quite difficult. Instead, I'd suggest adding an opt-in configuration that will add the N-2nd kernel of the currently booted OS to the dbx. Tracking the hash of the N-2nd kernel will require careful consideration, given that it will no longer be present on the filesystem in the default configuration of most distributions. A running list of kernel hashes could be maintained somewhere and head -n -2 of that list can be imported into the dbx during the hook.

Care should be taken to make sure the current (and ideally the former) kernel is (are) never imported into the dbx, as the dbx takes precedence over a valid signature.

Wrong kernel output after system update

What's the issue:

Sometimes, sbupdate outputs the wrong kernel in /boot partition which results in being unable to boot with an error similar to this:

Warning: /lib/modules/5.8.8-arch1-1/modules.devname not found - ignoring
                      ^ ^ ^ notice old kernel version

See this thread on BBS for more context.

How to reproduce the issue:

(don't try it unless you know what you're doing, it's annoying)

• Have an old (dangling) kernel version in /var/lib/modules/ along with your current kernel
• Run pacman -S systemd (I guess it'd also reproduce when running just sbupdate command, but note it does not reproduce with pacman -S linux)
• Reboot

Additional info:

As I understand the problem, I think the following events happen:

0. The pacman hook triggers because of the systemd package update
1. As there's no kernel present in systemd package, sbupdate decides to sign all kernels present in /var/lib/modules/
2. With some bad luck on the processing order, it gets the old kernel last which results in the old kernel being copied and signed to the output

Some remarks:

• The issue doesn't reproduce when updating linux package because it catches the new kernel file from standard input, so there's no confusion possible. This trick doesn't work when the hook triggers from a different package such as systemd.
• Does it really makes sense to process each kernel in a pipeline? As far as I understand, each signed kernel will be overwritten by the next one and eventually, only the last one will remain in the /boot partition. Am I missing something?
• Not sure what the proper fix to this bug is. Maybe if multiple kernels are found it could pick only the most recent one (based on lstat) and display some warning. And the kernel directory pattern in /var/lib/modules/ could be made configurable somehow.

Thanks.

Replace 'File' with 'Path' in Pacman Hooks

According to aplm-hooks(5)

File is a deprecated alias for Path and will be removed in a future release.

This part of the description for the Type trigger. Should 50-sbupdate-remove.hook and 95-sbupdate.hook be updated to follow this new specification?

SBAT support for new shim

The newer shim (shim-signed 15.4) requires a SBAT section for the EFI binary.

https://github.com/rhboot/shim/blob/main/SBAT.md

Please add support to sign kernels with an appropriate SBAT section to boot with the new shim-signed package.

Allow custom `output_name`

I use refind and want my /boot to look like this:

[root@Elizabeth ~]# ls /boot/
 EFI					    initramfs-linux-git.img			   initramfs-linux-zen.img   vmlinuz-linux		     vmlinuz-linux-intel-lts-sriov.efi	 vmlinuz-linux-zen
'System Volume Information'		    initramfs-linux-intel-lts-sriov-fallback.img   initramfs-linux.img	     vmlinuz-linux-drm-tip-git	     vmlinuz-linux-intel-lts-sriov.png	 vmlinuz-linux-zen.efi
 devtree				    initramfs-linux-intel-lts-sriov.img		   intel-ucode.img	     vmlinuz-linux-drm-tip-git.efi   vmlinuz-linux-lts			 vmlinuz-linux-zen.png
 drivers				    initramfs-linux-lts-fallback.img		   linux.efi		     vmlinuz-linux-drm-tip-git.png   vmlinuz-linux-lts.efi		 vmlinuz-linux.efi
 initramfs-linux-drm-tip-git-fallback.img   initramfs-linux-lts.img			   loader		     vmlinuz-linux-git		     vmlinuz-linux-lts.png		 vmlinuz-linux.img
 initramfs-linux-drm-tip-git.img	    initramfs-linux-next-git-fallback.img	   refind_linux.conf	     vmlinuz-linux-git.efi	     vmlinuz-linux-next-git		 vmlinuz-linux.img.png
 initramfs-linux-fallback.img		    initramfs-linux-next-git.img		   refind_local.cer	     vmlinuz-linux-git.png	     vmlinuz-linux-next-git.efi		 vmlinuz-linux.png
 initramfs-linux-git-fallback.img	    initramfs-linux-zen-fallback.img		   rescue.sh		     vmlinuz-linux-intel-lts-sriov   vmlinuz-linux-next-git.png		 vmlinuz-linux.save.efi

Note: I will move the unsinged files to a secure filesystem soon.

By default sbupdate appends -signed and does not prepend vmlinuz- to fix this I added the following to /etc/sbupdate.conf:

# Return output file path corresponding to an image
#   $1: configuration name
function output_name() {
  echo "${ESP_DIR}/${OUTPUT[$1]:-${OUT_DIR}/vmlinuz-$1.efi}"
}

This workaround works but feels rather hacky.
Official naming scheme support would be nice.
If my current solution is fine then I can offer to add a section to the readme and document it as a feature.

sbupdate for signing kernel modules too?

RedHat has implemented kernel-module signatures using some native functionality in the Kernel and their own signing keys/certs. Is there any way to get something like that automated with sbupdate to sign kernel modules for secure boot using your own keys and certificates that you're already using for secureboot, or is this something that you would need to do while building the kernel itself?

By the way, this tool is amazing!

Also, here is the documentation on how to enable it: https://www.kernel.org/doc/Documentation/module-signing.txt

Also, don't know how hard this would be, but if you can implement automated module signing, could it be done for dkms?

Feature Request: Sign fwupd EFI Loader

It would be nice to have sbupdate automatically sign the fwupd EFI loaders, instead of having to write a custom pacman hook that takes that over.

Additional info can be checked here: https://wiki.archlinux.org/index.php/Fwupd#Secure_Boot

Bashism in Makefile

The install target in the Makefile contains the following chunk:

$(INSTALL) -D -m 0644 -t "$(DESTDIR)/usr/share/libalpm/hooks" \
      hooks/{95-sbupdate.hook,50-sbupdate-remove.hook}

Unfortunately, brace extensions are not compatible with strict POSIX shells (like dash):

install: cannot stat 'hooks/{95-sbupdate.hook,50-sbupdate-remove.hook}': No such file or directory
make: *** [Makefile:14: install] Error 1

This issue can be fixed by either expanding the path manually or adding SHELL=bash.

sbupdate error

sbupdate give error if old kernel modules folder exist in /usr/lib/modules after remove old one all ok.
/usr/sbin/sbupdate: line 172: /usr/lib/modules/4.19.84-1-lts/pkgbase: No such file or directory
and https://www.archlinux.org/news/new-kernel-packages-and-mkinitcpio-hooks/

issue with systemd 252.1

I am not sure yet this is related to sbupdate but something fishy is going on and it seems related to the cmdline options passed to the kernel. so.

Since I updated to systemd 252.1 on my laptop, the boot breaks because of the error "Failed to start Loading Kernel Modules"
Specifically, my CMDLINE_DEFAULT in /etc/sbupdate.conf ends wtih i915.fastboot=1 but the error above is caused because there is garbage appended after the 1 of the parameter. So this trhows: i915: 1\ygyjfhgjfghj invalid parameter for fastboot

I thought that my FAT32 ESP was corrupt but it does not seem so

Simply reverting to systemd 251.7 fixes the problem???

Moreover, on my desktop, the boot is also broken because of /dev/vg/swap is not found by systemd, and the boot halts indefintely there.
I was thinking it is related to some lvm device not showing up, like I said in https://bugs.archlinux.org/task/76518

But now I am wondering because resume=/dev/vg/swap is also at the end of my CMDLINE_DEFAULT there. But I did not see any weird message lke above, So?

There again I downgraded systemd to 251.7

Allow `.cmdline` to be omitted

I use refind and secure boot with custom keys.
If .cmdline is present in the UKI it ignores all options passed by the bootloader.
However if no .cmdline is present bootloader options are accepted.

Workaround add the following to /etc/sbupdate.conf:

# Generate a signed kernel image
#   $1: configuration name
#   $2: kernel name
function update_image() {
  local linux="/boot/vmlinuz-$2"
  local initrd="${INITRD[$1]:-/boot/initramfs-$1.img}"
  local cmdline="${CMDLINE[$1]:-${CMDLINE_DEFAULT}}"
  local output; output="$(output_name "$1")"

  echo "Generating and signing $(basename "${output}")"

  # Create a combined binary with systemd EFI stub. For additional information see:
  #   https://github.com/systemd/systemd/blob/master/src/boot/efi/stub.c
  #   https://github.com/systemd/systemd/blob/master/test/test-efi-create-disk.sh
  #
  # Prepend initramfs files are joined with the main initramfs in one image. Refer to:
  #   https://www.kernel.org/doc/Documentation/early-userspace/buffer-format.txt
  #   https://www.kernel.org/doc/Documentation/x86/microcode.txt


  #  --add-section .cmdline=<(printf "%s\0" "${cmdline}")            --change-section-vma .cmdline=0x30000  \

  objcopy \
    --add-section .osrel="/etc/os-release"                          --change-section-vma .osrel=0x20000    \
    --add-section .splash="${SPLASH}"                               --change-section-vma .splash=0x40000   \
    --add-section .linux="${linux}"                                 --change-section-vma .linux=0x2000000  \
    --add-section .initrd=<(cat "${INITRD_PREPEND[@]}" "${initrd}") --change-section-vma .initrd=0x3000000 \
    "${EFISTUB}" "${output}"
  wait $!

  # Sign the resulting output file
  sign_file --output "${output}" "${output}"
}

Official support for this would be nice.
As it reduces the security sbupdate could emit a warning if the DEFAULT_CMDLINE config is unset and skip embedding a .cmdline.

Use calculated, flexible section-vma offsets instead of hardcoded ones

objcopy in https://github.com/andreyv/sbupdate/blob/master/sbupdate#L170 uses hard-coded section-vma positions:

objcopy \
    --add-section .osrel="/etc/os-release"                          --change-section-vma .osrel=0x20000    \
    --add-section .cmdline=<(echo -n "${cmdline}")                  --change-section-vma .cmdline=0x30000  \
    --add-section .splash="${SPLASH}"                               --change-section-vma .splash=0x40000   \
    --add-section .linux="${linux}"                                 --change-section-vma .linux=0x2000000  \
    --add-section .initrd=<(cat "${INITRD_PREPEND[@]}" "${initrd}") --change-section-vma .initrd=0x3000000 \
    "${EFISTUB}" "${output}"

0x20000 for osrel, 0x30000 for cmdline, 0x40000 for splash, and so on.

The Arch Wiki in https://wiki.archlinux.org/title/Unified_kernel_image#Manually however recommends more flexible section-vma positions, that depend on the size of the sections / parts before. They first calculate the offsets:

stub_line=$(objdump -h "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" | tail -2 | head -1)
stub_size=0x$(echo "$stub_line" | awk '{print $3}')
stub_offs=0x$(echo "$stub_line" | awk '{print $4}')
osrel_offs=$((stub_size + stub_offs))
cmdline_offs=$((osrel_offs + $(stat -c%s "/usr/lib/os-release")))
splash_offs=$((cmdline_offs + $(stat -c%s "/etc/kernel/cmdline")))
linux_offs=$((splash_offs + $(stat -c%s "/usr/share/systemd/bootctl/splash-arch.bmp")))
initrd_offs=$((linux_offs + $(stat -c%s "vmlinuz-file")))

... and then use these offsets instead:

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="initrd-file" \
    --change-section-vma .initrd=$(printf 0x%x $initrd_offs) \
    "/usr/lib/systemd/boot/efi/linuxx64.efi.stub" "linux.efi"

I think this flexible approach is much better, because it can make the resulting UEFI kernel image much smaller; which makes booting a little bit faster.

Analysing the generated UEFI image and getting the sections is still easily possible with tools like objdump, so I don't see any added value in using hard-coded offsets:

$ objdump -h linux-signed.efi

linux-signed.efi:     file format pei-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         00006dd0  0000000000003000  0000000000003000  00000400  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .reloc        0000000c  000000000000a000  000000000000a000  00007200  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         000028f0  000000000000b000  000000000000b000  00007400  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  3 .dynamic      00000100  000000000000e000  000000000000e000  00009e00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .rela         00000ed0  000000000000f000  000000000000f000  0000a000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .dynsym       00000018  0000000000010000  0000000000010000  0000b000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .sbat         00000108  0000000000012000  0000000000012000  0000b200  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .sdmagic      00000030  0000000000012120  0000000000012120  0000b400  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .osrel        0000011d  0000000000020000  0000000000020000  0000b600  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .cmdline      00000070  0000000000030000  0000000000030000  0000b800  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .splash       0005c572  0000000000040000  0000000000040000  0000ba00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 11 .linux        00a7e340  0000000002000000  0000000002000000  00068000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 12 .initrd       01c6a282  0000000003000000  0000000003000000  00ae6400  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA

Should I make a pull request for this improvement?

How to load fallback initramfs?

I set an additional initramfs in sbupdate config like this:

INITRD[linux]=/boot/initramfs-linux.img
INITRD[linux]=/boot/initramfs-linux-fallback.img

And I noticed that when I added these two lines the signed efi doubled in size, but I have no idea how to boot it with the fallback initramfs. I didn't see a section about this in the README.md.

Feature request: no splash image

I'd just like to not use a splash image but a simple black screen. AFAIK it's not currently possible.

sbudpate fails when using grub sigchecks

GRUB2's external signature check leaves a signature for each file in /boot/ with the name filename.sig.

This seems to break the kernel detection making it fail on signing the initramfs:

(10/11) Updating UEFI kernel images...
Generating and signing linux-signed.efi
warning: gap in section table:
    .sbat   : 0x0000de00 - 0x0000e000,
    .sdmagic: 0x0000e120 - 0x0000e320,
gaps in the section table may result in different checksums
warning: data remaining[34759168 vs 34770271]: gaps between PE/COFF sections?
warning: gap in section table:
    .sbat   : 0x0000de00 - 0x0000e000,
    .sdmagic: 0x0000e120 - 0x0000e320,
gaps in the section table may result in different checksums
warning: data remaining[34759168 vs 34770272]: gaps between PE/COFF sections?
Signing Unsigned original image
Generating and signing linux.sig-signed.efi
cat: /boot/initramfs-linux.sig.img: No such file or directory

Solution might be to simly ignore all *.sig files in /boot while performing the secure boot signing.

stub doesn't load properly from non-secure boot

I have run across an interesting issue,

Where the stub generated from sbupdate loads from shim-->refind-->stub-->linux perfectly normal when using secure boot. But when reverting to non-secure boot, however, I am unable to get the stub to load up linux properly via refind, and it crashes to an emergency shell.

note: I am able to load the linux kernel directly and pass the correct parameters from refind in non-secure mode, and all will load as normal. It appears only when loading from the stub in non-secure boot to be the issue.

How do I go about debugging this? Any ideas what may be the cause?

Thanks.

Feature request: Include functionality

I am distributing configs through etckeeper across my computers. For my use case, it could be useful to have a line such as #include /etc/sbupdate.local.conf, so I could give generic options in /etc/sbupdate.conf, which can be shared accross devices; and device specific info on some file that will be distributed in some other way.

EXTRA_SIGN does not work when sbupdate is called by hook

When the sbupdate hook is called during an update, it does not sign systemd-boot images. Here is the console output:

(10/13) Updating UEFI kernel images...
Generating and signing linux-signed.efi
warning: data remaining[24715264 vs 24724876]: gaps between PE/COFF sections?
warning: data remaining[24715264 vs 24724880]: gaps between PE/COFF sections?
Signing Unsigned original image
warning: data remaining[80384 vs 91584]: gaps between PE/COFF sections?
No signature table present
warning: failed to verify /efi/EFI/BOOT/BOOTX64.EFI
warning: data remaining[80384 vs 91584]: gaps between PE/COFF sections?
No signature table present
warning: failed to verify /efi/EFI/systemd/systemd-bootx64.efi

However when run with # sbupdate from a console after an update it works fine with the output:

Generating and signing linux-signed.efi
warning: data remaining[24715264 vs 24724876]: gaps between PE/COFF sections?
warning: data remaining[24715264 vs 24724880]: gaps between PE/COFF sections?
Signing Unsigned original image
Generating and signing linux-hardened-signed.efi
warning: data remaining[25086464 vs 25096076]: gaps between PE/COFF sections?
warning: data remaining[25086464 vs 25096080]: gaps between PE/COFF sections?
Signing Unsigned original image
warning: data remaining[80384 vs 91584]: gaps between PE/COFF sections?
No signature table present
Signing /efi/EFI/BOOT/BOOTX64.EFI
warning: data remaining[80384 vs 91584]: gaps between PE/COFF sections?
Signing Unsigned original image
warning: data remaining[80384 vs 91584]: gaps between PE/COFF sections?
No signature table present
Signing /efi/EFI/systemd/systemd-bootx64.efi
warning: data remaining[80384 vs 91584]: gaps between PE/COFF sections?
Signing Unsigned original image