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

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

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

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!

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

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

@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?

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

OK. I appreciate the reply.

@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?

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