MoKManager (BOOT/mmx64.efi) in Bottlerocket Secure Boot

[rajivr]

From what I understand, in a GPOS context mmx64.efi is useful in enrolling machine owner keys in order to load custom kernels along side vendor provided kernels.

I was wondering if there was some reason to build, sign and install mmx64.efi in Bottlerocket?

In Bottlerocket, the shim bootx64.efi would load grubx64.efi which would then load the kernel via grub.cfg using GPT prio.

Since Bottlerocket is an SPOS, perhaps there is no need to fallback to MokManager when bootx64.efi is unable to load grubx64.efi.

Rather than maintaining a patch to prevent init_grub from loading MokManager, we could perhaps simply not package mmx64.efi, and just let secure boot fail if ever grubx64.efi gets tampered with.

Please let me know what you think.

[bcressey]

I was wondering if there was some reason to build, sign and install mmx64.efi in Bottlerocket?

It's possible - via installing and running mokutil in the admin container - to get the system to a state where shim wants to run MokManager, and the serial console can be used to finalize the enrollment of a new key.

If MokManager is missing, then the system ends up with a boot failure that can't be cleared up by simply rebooting; on reboot, shim will load its EFI variable again, find the same request to enroll a new key, and fail to load MokManager.

Once the system was in this state, I couldn't think of a way to un-brick it again. I felt this was too harsh a penalty to pay for experimenting with mokutil, which is why the EFI binary is packaged and signed.

[rajivr]

I felt this was too harsh a penalty to pay for experimenting with mokutil, which is why the EFI binary is packaged and signed.

I agree it would be harsh penalty 😄

Similar to GRUB_SET_PRIVATE_VAR, would you be open to having an option to disable copying of mmx64.efi into ESP?

[bcressey]

Similar to GRUB_SET_PRIVATE_VAR, would you be open to having an option to disable copying of mmx64.efi into ESP?

In the abstract, I'd prefer a patch to disable all MokManager interactions in shim, though it would depend on how invasive or tricky it ended up being. Even though it works, I don't think the MokManager support is very useful in the contexts where Bottlerocket is likely to be deployed, so if it could go away painlessly that would be best.

[rajivr]

Even though it works, I don't think the MokManager support is very useful in the contexts where Bottlerocket is likely to be deployed, so if it could go away painlessly that would be best.

I agree. Thanks a lot for the quick replies 🙏. Really appreciate it!

PS: I am still very new to Bottlerocket, and mostly exploring it in my free time. Hopefully early next year, I should have my development environment (qemu, etc.,) set up for Bottlerocket and will try to contribute in some form.

[bcressey]

Hopefully early next year, I should have my development environment (qemu, etc.,) set up for Bottlerocket and will try to contribute in some form.

FWIW, there's a start-local-vm helper script for the QEMU invocation.

I use it like so:

./tools/start-local-vm \
  --arch x86_64 \
  --variant metal-dev \
  --inject-file net.toml \
  --firmware-code OVMF_CODE.secboot.fd \
  --firmware-vars OVMF_VARS.secboot-local.fd

net.toml:

version = 1

[enp0s16]
dhcp4 = true

OVMF_CODE.secboot.fd and OVMF_VARS.secboot-local.fd:

# provides the virt-fw-vars tool and edk2
dnf install python3-virt-firmware edk2-ovmf

cp /usr/share/edk2/ovmf/OVMF_CODE.secboot.fd .

virt-fw-vars \
  --input /usr/share/edk2/ovmf/OVMF_VARS.secboot.fd \
  --set-json ./sbkeys/local/efi-vars.json \
  --output OVMF_VARS.secboot-local.fd

It's also possible to test aarch64 this way, but (at least on Fedora) it requires a custom build of edk2 to enable the Secure Boot feature, which is kind of a pain.

[rajivr]

Thanks 🙏 @bcressey.

My primary work environment is NixOS. Hopefully I should be able to get this to work on NixOS 🤞 early next year. Happy Holidays! 🎄