#3278 PR open: Autodetect secure boot via mokutil and guess the secure boot shim¶
Labels: enhancement
schlomo opened issue at 2024-07-12 11:31:¶
Fixes #3276
Relax-and-Recover (ReaR) Pull Request Template¶
Please fill in the following items before submitting a new pull request:
Pull Request Details:¶
-
Type: Enhancement
-
Impact: Normal
-
Reference to related issue (URL):
#3276
- How was this pull request tested?
Manually on OL9u3 with secure boot and on Ubuntu 22 and openSUSE Leap 15.4 without secure boot
- Description of the changes in this pull request:
use mokutil to check for secure boot and guess the shim file - failing
back to the previous behaviour if this doesn't work.
probably #3277 is a better or more complete implementation, however this one just adds a single file to automate the configuration that I had to add manually so far.
schlomo commented at 2024-07-12 12:32:¶
Ubuntu 22.04 ✔️¶
root@rear-u2404:/src/rear# REAR_VAR=/tmp/rear ./usr/sbin/rear -v mkrescue
Relax-and-Recover 2.7 / Git
Running rear mkrescue (PID 20965 date 2024-07-12 12:26:58)
Using log file: /tmp/rear/log/rear/rear-rear-u2404.log
Running workflow mkrescue on the normal/original system
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Secure Boot auto-configuration using '/boot/efi/EFI/ubuntu/shimx64.efi' as UEFI bootloader
Using autodetected kernel '/boot/vmlinuz-6.8.0-38-generic' as kernel in the recovery system
Creating disk layout
Overwriting existing disk layout file /tmp/rear/lib/rear/layout/disklayout.conf
Verifying that the entries in /tmp/rear/lib/rear/layout/disklayout.conf are correct
Created disk layout (check the results in /tmp/rear/lib/rear/layout/disklayout.conf)
Creating recovery system root filesystem skeleton layout
Skipping 'lo': not bound to any physical interface.
Using '/boot/efi/EFI/ubuntu/shimx64.efi' as UEFI Secure Boot bootloader file
Copying logfile /tmp/rear/log/rear/rear-rear-u2404.log into initramfs as '/tmp/rear-rear-u2404-partial-2024-07-12T12:27:04+00:00.log'
Copying files and directories
Copying binaries and libraries
Copying only currently loaded kernel modules (MODULES contains 'loaded_modules') and those in MODULES_LOAD
Omit copying files in /lib*/firmware/ (FIRMWARE_FILES='no')
Testing that the recovery system in /var/tmp/rear.TtxlkmoYTi1argv/rootfs contains a usable system
/usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-255.so requires libraries where 'ldd' shows 'not found'
/usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-255.so requires libsystemd-shared-255.so which was not found by 'ldd' but exists as /var/tmp/rear.TtxlkmoYTi1argv/rootfs/usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-255.so
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (78 MiB) in 10 seconds
Did not find /boot/grub/locale files (minor issue for UEFI ISO boot)
Making ISO image
Wrote ISO image: /tmp/rear/lib/rear/output/rear-rear-u2404.iso (197M)
Copying resulting files to nfs location
Saving /tmp/rear/log/rear/rear-rear-u2404.log as rear-rear-u2404.log to nfs location
Copying result files '/tmp/rear/lib/rear/output/rear-rear-u2404.iso /var/tmp/rear.TtxlkmoYTi1argv/tmp/VERSION /var/tmp/rear.TtxlkmoYTi1argv/tmp/README /var/tmp/rear.TtxlkmoYTi1argv/tmp/rear-rear-u2404.log' to /var/tmp/rear.TtxlkmoYTi1argv/outputfs/rear-u2404 at nfs location
Exiting rear mkrescue (PID 20965) and its descendant processes ...
Running exit tasks
root@rear-u2404:/src/rear#
and rescue systemm boots:
pcahyna commented at 2024-07-12 12:50:¶
I need to check why is my approach so much more complicated than this, but IIRC this is related to the code comment:
# The good solution would check the EFI variables for the bootloader
# that is used to boot the system. But this is not implemented yet for
# secure boot.
#
# The code in usr/share/rear/rescue/default/850_save_sysfs_uefi_vars.sh
# could be used as a starting point for this, however currently
# it tries to read the actual boot loader# used only as a last resort
# if well-known files are not found.
Indeed, in https://github.com/rear/rear/pull/3277 I check whether the EFI variables point to the shim as the initial bootloader, and use file pattern matching only as last resort.
schlomo commented at 2024-07-12 13:01:¶
OpenSUSE Leap 15.6 ✔️¶
it required installing xorriso as mentioned in #3084
rear-sle15sp6:/src/rear # REAR_VAR=/tmp/rear ./usr/sbin/rear -v mkrescue
Relax-and-Recover 2.7 / Git
Running rear mkrescue (PID 25196 date 2024-07-12 14:54:25)
Using log file: /tmp/rear/log/rear/rear-rear-sle15sp6.log
Running workflow mkrescue on the normal/original system
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Secure Boot auto-configuration using '/boot/efi/EFI/opensuse/shim.efi' as UEFI bootloader
Using autodetected kernel '/boot/vmlinuz-6.4.0-150600.23.7-default' as kernel in the recovery system
Creating disk layout
Overwriting existing disk layout file /tmp/rear/lib/rear/layout/disklayout.conf
SLES12-SP1 (and later) btrfs subvolumes setup needed for /dev/sda2 (default subvolume path contains '@/.snapshots/')
Added /dev/sda2 to BTRFS_SUBVOLUME_SLES_SETUP in /var/tmp/rear.esjRZPTwqJlMZEb/rootfs/etc/rear/rescue.conf
Using sysconfig bootloader 'grub2-efi' for 'rear recover'
Verifying that the entries in /tmp/rear/lib/rear/layout/disklayout.conf are correct
Created disk layout (check the results in /tmp/rear/lib/rear/layout/disklayout.conf)
Creating recovery system root filesystem skeleton layout
Skipping 'lo': not bound to any physical interface.
Using '/boot/efi/EFI/opensuse/shim.efi' as UEFI Secure Boot bootloader file
Copying logfile /tmp/rear/log/rear/rear-rear-sle15sp6.log into initramfs as '/tmp/rear-rear-sle15sp6-partial-2024-07-12T14:54:30+02:00.log'
Copying files and directories
Copying binaries and libraries
Copying only currently loaded kernel modules (MODULES contains 'loaded_modules') and those in MODULES_LOAD
Omit copying files in /lib*/firmware/ (FIRMWARE_FILES='no')
Testing that the recovery system in /var/tmp/rear.esjRZPTwqJlMZEb/rootfs contains a usable system
/usr/lib64/systemd/libsystemd-core-254.so requires libraries where 'ldd' shows 'not found'
/usr/lib64/systemd/libsystemd-core-254.so requires libsystemd-shared-254.so which was not found by 'ldd' but exists as /var/tmp/rear.esjRZPTwqJlMZEb/rootfs/usr/lib64/systemd/libsystemd-shared-254.so
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (67 MiB) in 8 seconds
Making ISO image
Wrote ISO image: /tmp/rear/lib/rear/output/rear-rear-sle15sp6.iso (188M)
Copying resulting files to nfs location
Saving /tmp/rear/log/rear/rear-rear-sle15sp6.log as rear-rear-sle15sp6.log to nfs location
Copying result files '/tmp/rear/lib/rear/output/rear-rear-sle15sp6.iso /var/tmp/rear.esjRZPTwqJlMZEb/tmp/VERSION /var/tmp/rear.esjRZPTwqJlMZEb/tmp/README /var/tmp/rear.esjRZPTwqJlMZEb/tmp/rear-rear-sle15sp6.log' to /var/tmp/rear.esjRZPTwqJlMZEb/outputfs/rear-sle15sp6 at nfs location
Exiting rear mkrescue (PID 25196) and its descendant processes ...
Running exit tasks
Rescue system boots and shows secure boot to be active:
schlomo commented at 2024-07-12 13:46:¶
@pcahyna to summarise: I'd suggest merging this as a step towards better secure boot support. It is meant as a simple fix to autoconfigure the shim. Nothing more.
schlomo commented at 2024-07-13 22:10:¶
@pcahyna I thought about what you wrote and here is another idea: What about unconditionally using the shim if it is available?
In https://github.com/rear/rear/blob/76791f9b1a821ed019063ced48e502ba9a468857/usr/share/rear/prep/Linux-i386/370_detect_secure_boot.sh I tried to put this together and this code managed to recover a non-secure-boot Ubuntu 22.04 on a secure boot recovery system, effectively migrating the system onto secure boot :-)
I still have a problem with it: On a non-secure boot system with shim the grub menu doesn't load automatically, but the system stops at the grub prompt.
jsmeix commented at 2024-07-17 12:06:¶
Only as a minor side note by the way:
I am wondering if the right spelling is:
'secure boot' or 'Secure Boot'?
Curently we use both in ReaR (and also 'Secure booting').
But
https://en.wikipedia.org/wiki/UEFI#Secure_Boot
indicates the right spelling is 'Secure Boot'.
jsmeix commented at 2024-07-17 12:14:¶
@schlomo
thank you for this valuable improvement step!
I do fully agree with your reasoning in your
https://github.com/rear/rear/pull/3277#issuecomment-2232537772
Better moving forward little step by little step
(usually two steps forward, one step back and one step sideways)
than to not move forward at all.
In particular in this case where all is ReaR internal code
(except the small info comment in default.conf)
we can later "just" adapt and enhance things as we like.
schlomo commented at 2024-07-17 12:32:¶
Ok, thank you all for the discussion.
If I don't hear a request to change stuff and if nobody vetoes this then I'll merge it Thursday evening
pcahyna commented at 2024-07-18 09:59:¶
I thought about what you wrote and here is another idea: What about unconditionally using the shim if it is available?
In https://github.com/rear/rear/blob/76791f9b1a821ed019063ced48e502ba9a468857/usr/share/rear/prep/Linux-i386/370_detect_secure_boot.sh I tried to put this together and this code managed to recover a non-secure-boot Ubuntu 22.04 on a secure boot recovery system, effectively migrating the system onto secure boot :-)
I still have a problem with it: On a non-secure boot system with shim the grub menu doesn't load automatically, but the system stops at the grub prompt.
@schlomo what do you mean? The GRUB menu of the recovered system, or of the rescue image? And is it a problem only with your alternative implementation at https://github.com/rear/rear/blob/76791f9b1a821ed019063ced48e502ba9a468857/usr/share/rear/prep/Linux-i386/370_detect_secure_boot.sh or also with the current changes in this PR?
In any case, I would consider this a serious regression - the current code just works on a non Secure Boot with shim (except that after recovery the bootloader is set to GRUB directly bypassing the shim, as I already mentioned earlier - but the system works fine).
schlomo commented at 2024-07-18 15:25:¶
@schlomo what do you mean? The GRUB menu of the recovered system, or of the rescue image? And is it a problem only with your alternative implementation at https://github.com/rear/rear/blob/76791f9b1a821ed019063ced48e502ba9a468857/usr/share/rear/prep/Linux-i386/370_detect_secure_boot.sh or also with the current changes in this PR?
In any case, I would consider this a serious regression - the current code just works on a non Secure Boot with shim (except that after recovery the bootloader is set to GRUB directly bypassing the shim, as I already mentioned earlier - but the system works fine).
that was only with the alternative implementation that used the shim whenever found. I'll double check to be sure.
schlomo commented at 2024-07-19 06:46:¶
I slightly reworked the code to bail out if Secure Boot is active but we cannot find a shim:
...
Found EFI system partition /dev/sda1 on /boot/efi type vfat
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Using '/usr/bin/xorrisofs' to create ISO filesystem images
ERROR:
====================
BUG in /src/rear/usr/share/rear/prep/Linux-i386/370_detect_secure_boot.sh line 22:
Secure Boot is active, cannot auto-configure Secure Boot support:
No shim.efi or shimx64.efi found in /boot/efi/EFI/*/ directory.
As a workaround you can set SECURE_BOOT_BOOTLOADER to the correct shim.efi or shimx64.efi file
--------------------
Please report it at https://github.com/rear/rear/issues
and include all related parts from /tmp/rear/log/rear/rear-rear-u2404.log
preferably the whole debug information via 'rear -D mkrescue'
====================
Some latest log messages since the last called script 370_detect_secure_boot.sh:
2024-07-19 06:45:33.920589412 Entering debugscript mode via 'set -x'.
/usr/bin/mokutil
Aborting due to an error, check /tmp/rear/log/rear/rear-rear-u2404.log for details
schlomo commented at 2024-07-19 06:49:¶
@rear/contributors I consider this PR now ready for merging and plan to do so on Sunday.
pcahyna commented at 2024-07-19 11:04:¶
Side note: what's up with the Build Packages step?
I see:
== Building Pacman package rear-2.7-git.5498.18b69305.securebootautoconfigure ==
rm -rf /tmp/rear-2.7-git.5498.18b69305.securebootautoconfigure
mkdir -p /tmp/rear-2.7-git.5498.18b69305.securebootautoconfigure
cp packaging/arch/PKGBUILD.local /tmp/rear-2.7-git.5498.18b69305.securebootautoconfigure/PKGBUILD
cp dist/rear-2.7-git.5498.18b69305.securebootautoconfigure.tar.gz /tmp/rear-2.7-git.5498.18b69305.securebootautoconfigure/
cd /tmp/rear-2.7-git.5498.18b69305.securebootautoconfigure ; \
sed -i -e 's/VERSION/202407190647/' \
-e 's/SOURCE/rear-2.7-git.5498.18b69305.securebootautoconfigure.tar.gz/' \
-e 's/MD5SUM/21273efd7ea2f37e0c9dff744c848c58/' \
PKGBUILD ; \
chmod -R o+rwX . ; ls -l ; \
runuser -u nobody -- makepkg -c
total 956
-rw-r--rw- 1 root root 729 Jul 19 07:04 PKGBUILD
-rw-r--rw- 1 root root 974272 Jul 19 07:04 rear-2.7-git.5498.18b69305.securebootautoconfigure.tar.gz
==> ERROR: Cannot find the debugedit binary required for including source files in debug packages.
make: *** [Makefile:302: pacman] Error 15
if Pacman packages can't be built, this step should be removed from the CI run. We should not get used to CI jobs failing being something normal.
gdha commented at 2024-07-19 11:13:¶
@schlomo
==> ERROR: Cannot find the debugedit binary required for including source files in debug packages.
make: *** [Makefile:302: pacman] Error 15if Pacman packages can't be built, this step should be removed from the CI run. We should not get used to CI jobs failing being something normal.
Just add debugedit to the line
https://github.com/rear/rear/blob/master/tools/run-in-docker#L100
[Export of Github issue for rear/rear.]