Mender and efi-secure-boot on intel-corei7-64

General Discussions
1

Hello,

I’m attempting to integrate efi-secure-boot with Mender on an intel-corei7-64 Yocto target platform. I can get to the point where the UEFI firmware is validating GRUB (bootx64.efi) and grub.cfg but bzImage validation fails. It appears the issue is that bzImage and bzImage.p7b are in /boot instead of /boot/efi.

I have seen this thread, but it doesn’t have a solution: https://hub.mender.io/t/mender-and-efi-secure-boot/1943

Has anyone been successful in using efi-secure-boot together with Mender?

Is it possible to install the bzImage* files into /boot/efi?

Best,
Casey

2

Hi @esscrb

Thanks for touching upon that topic. Just wanted to give you a short heads up that I can try and look into it, but not until mid of next week as Easter is coming up. I’ll get back to once I have something to share.

Greetz,
Josef

3

Thank you @TheYoctoJester. I’ve been trying to figure out how to solve this for over a week, to no avail. Any pointers you or anyone else can provide are greatly appreciated!

4

Hi @esscrb,

Sorry for not yet having proper news. By thinking a bit more about it, the key problem is that the Mender A/B scheme needs the kernel to be on the system partition in order to update it. Can you maybe share the partition layout of the device in question? If the search is defined by Grub, then it should be possible to adjust it accordingly.

Greetz,
Josef

6

Hi @TheYoctoJester,

Here is our partition layout:

/dev/sda1 (boot partition) is mounted under /boot/efi
/dev/sda2 is the A partition
/dev/sda3 is the B partition
/dev/sda4 (data partition) is mounted under /data

We do boot via Grub.

I still think the issue is that SELoader requires bzImage to be in /boot/efi

Again, thanks for any help!

Casey

7

@drewmoseley I came across your replies in thread Mender and efi-secure-boot when researching my current issue. Were you ever able to get mender and efi-secure-boot working on intel-corei7-64?

8

No, sorry. That project got put on hold and the work was never finished up.

9

OK. I appreciate the reply.

10

@TheYoctoJester and others: I’ve been looking into one possible solution suggested by meta-mender-kernel to solve the kernel being located in /boot. It solves the problem by using shim & MOK to verify the kernel. However, the solution requires INITRAMFS_IMAGE_BUNDLE and our system isn’t using an initramfs.

I’m curious if we might use a similar approach in our system, but without an initramfs i.e. use shim to verify the kernel on boot. Is that a wise approach, or is it a fool’s errand?

11

Hi @esscrb!

The idea is not bad, but involves a number of drawbacks as far as I understand it.

First, you probably can’t get rid of the initramfs, because this is where the crypto access happens. Second, pulling the bundled kernel out of the partition means that upgrading it needs additional magic and scripting as it doesn’t happen on the fly anymore.

I personally had even hoped that the 'meta-secure-core` layer fixes those issues due to the different approach. Seems I was mistaken. :frowning:

For my personal opinion, I think the integration/combination of both might do the trick in the end, but it is certainly not trivial.

Greetz,
Josef

12

Hi @TheYoctoJester et al:

I thought I should post an update after some weeks of working through this problem.

After talking with Josef we came to the conclusion that since the devices in question are using USB updates rather than OTA, the need for A/B rollback isn’t strictly necessary. After all, a human will be present to initiate & monitor the updates via USB and can take necessary actions upon update failure.

The approach we’re taking now is to first enable UEFI Secure Boot using meta-secure-core/meta-efi-secure-boot and adding some tweaks to the Mender grub.cfg fragments that end up composing the /boot/efi/EFI/BOOT/grub.cfg file. That’s working now!

The Secure Boot configuration portion in our .conf file looks like this:

# Add Secure Boot EFI and TPM2 tools
MACHINE_FEATURES_append = " tpm2"
DISTRO_FEATURES_append = " security tpm2 efi-secure-boot "
IMAGE_INSTALL_append = " tpm2-tools libtss2-tcti-device efitools seloader "

# disable Machine Owner Keys (MOK) secure boot
MOK_SB = ""

SIGNING_MODEL := "user"

# set secureboot key directory for this configuration
UEFI_SB_KEYS_DIR := "${SECUREBOOT_KEY_DIR}/${MACHINE}"

That got us a signed grub (bootx64.efi), grub.cfg, and SELoader EFI binary. However, there were still a couple of issues. First, bzImage and bzImage.p7b (the detached signature) need to be installed to the boot partition (mounted under /boot/efi on the running system). That was a straight forward addition to .conf:

IMAGE_BOOT_FILES_append = " \
                            ${KERNEL_IMAGETYPE} \
                            ${KERNEL_IMAGETYPE}${SB_FILE_EXT} \
                          "

We then struggled with Grub being able to work with mok2verify from the SELoader to verify & load bzImage. It turned out that the path that Grub looks for the kernel needs to have the ptable_type and partition number explicitly specified and the 90_mender_boot_grub.cfg fragment isn’t setting ptable_type early enough. Effectively, we force mender_kernel_path="(hd0,gpt1)" and viola we have a verified kernel and the Secure Boot completes and launches the rest of the system.

So that gets us to a working initial build. The next steps for us will involve a) using a mender state script to copy bzImage{.p7b} from the updated $rootfs/boot/ directory onto /boot/efi; and b) committing the update after the copy (or failing the update if something went wrong).

I’ll update this topic again with our progress.

Thanks,
Casey