Amendment to the Ubuntu shim: Introducing stubble

[julian-klode]

As previously discussed in the video meeting, we plan to introduce a new variant of systemd-stub, called "stubble".

You can find its code at https://github.com/canonical/stubble

Stubble removes most of the unused systemd-stub features, but also importantly:

• Allows external initrds to be supplied by the boot loader so we can build "classic" Ubuntu kernels where the initrd is generated locally, but can bundle signed DTBs with our kernel.
• Stubble changes the handling of EFI_LOADED_IMAGE to the same used in grub, reusing the parent handle, as a firmware can dereference the image handle into a wider struct, so a custom one does not work (as we found out with peimage prior) (potentially to be upstreamed)

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
stubble,1,Canonical,stubble,2,https://github.com/canonical/stubble
stubble.ubuntu,1,Canonical,stubble,2-1,https://launchpad.net/ubuntu/+source/stubble

Please let us know if you have any concerns.

[SherifNagy]

@jsetje @vathpela anyone working on reviewing that code?

[tobhe]

As promised yesterday here's an updated list of changes we made (minus all the code we deleted):

• Allows external initrds to be supplied by the boot loader so we can build "classic" Ubuntu kernels where the initrd is generated locally, but can bundle signed DTBs with our kernel.
• Stubble changes the handling of EFI_LOADED_IMAGE to the same used in grub, reusing the parent handle, as a firmware can dereference the image handle into a wider struct, so a custom one does not work (as we found out with peimage prior) (potentially to be upstreamed
• Adds a HWID lookup table database in hwids/
• Implements stricter dtb matching by not allowing ambiguous properties like MANUFACTURER + FAMILY
• Doesn't set NX_COMPAT flag when it isn't NX compatible

[jsetje]

I've taken a look at it. In general this seems like a really nice feature to fix up what we know about a platform and make it work.

The real risk with this is that much like you can't sign a kernel that has an inappropriate posture, you also can't sign an image with a device tree that allows things it shouldn't. Since the DTBs are signed as part of the kernel I assume all the usual rules and review processes apply, so this should be fine.

[tobhe]

Thanks for the review!

The real risk with this is that much like you can't sign a kernel that has an inappropriate posture, you also can't sign an image with a device tree that allows things it shouldn't. Since the DTBs are signed as part of the kernel I assume all the usual rules and review processes apply, so this should be fine.

Indeed. All dtbs we embed come from the kernel package and have to go through the regular review process. We also make sure we don't match too opportunistically to prevent DTBs meant for other devices to be loaded by accident.

[Conan-Kudo]

This is also going to affect Fedora too: https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems

Do we need to do something special for it to be applicable for us as well?

[julian-klode]

We have a Rust rewrite in

https://github.com/canonical/lace

[julian-klode]

Let's close this and move rust-based into new issue (#519)