Note that we currently ship a subset of rhboot/grub secureboot patches for EFI x86_64, modified to support ARM64.

The packaging of them is a bit convoluted, given that they continuously are getting reviewed and have not yet been merged upstream despite being 9 years old.

I hope it will be quicker to get powerpc patches into upstream, however, it will take time for them to get security review and accepted. Until they are accepted, please maintain public git repository from which we can pull in the patches. Ideally, with branches, per upstream tag, rebased and maintained on ongoing basis from until, and indefinitely. Unless of course they make into upstream.

Ubuntu's packaging, with patches applied is maintained at https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu you could choose to push to launchpad too, and rebase onto "ubuntu" branch which is always the packaging for the current devel series. At the moment that is hirsute. Once series goes stable named branches appear, i.e. "focal". Those branches look very odd, because they have debian/patches that have been serialized from git commits that have been merged already using git-dpm. Thus the tree has many merged commits, but the code after git clone should look as the source tree we are building. Thus ideally / hopefully, your patches rebase/merge onto "ubuntu" branch cleanly. I did not try this yet.

You must on the ongoing basis support enrolling arbitrary test key, and using it for testing. Launchpad has PPA archives, which allow Ubuntu developers build and sign packages. These archives create on-the-fly signing keys and allow one to upload and sign new experimental grub builds, but also kernels. Similar to how we continuously ask for testing secure-boot/lock-down of kernel signed with ephemeral test keys; we will do so with grub as well. Similarly you too, can upload packages to ubuntu PPA with a copy of a kernel, to observe it getting signed and published as debs with signed bootloader & kernel and the details of the signing key. Once all the necessary packaging is in place. We already have this requirement for the Power kernel enablement, however currenty the turn-around times of testing that are very long and have almost breached the timelines for new kernel uploads. If grub/kernel development is unreasonably delayed on testing new releases, we would be turning off signing with production keys in order to avoid revocation event.

Does existing / old firmware handle signed grub binaries just fine?

Ideally, we prefer to always use and install signed binaries. Regardless if secureboot is on, or off. Such that users can migrate disks and enable secureboot at a later point. Failing that, we'd need something similar to --uefi-secure-boot flag in grub-install to control and be sensitive to signed bits. But if you notice for x86 today we always check for signed grub and install that, in preference to installing any other images.

For the installer .iso - is there any signing required there, or will the .iso images remain unchanged?

I will try to prepare sample test packages. However it is not quite so quick. This will not be done instantly.

W.r.t. grub2 versions you will observe that the current grub2 we ship is quite a lot patched 2.04. We hope to move to 2.06 but i'm not yet sure if it will make it into 21.04 or if it will be done in 21.10 timeframe.

What are your expectations for landing this? Given the amount of testing, and back and forth it will require it may take time. At the moment we have one production OPAL singing key, and we have one unused spare one. If we make a mistake, it will be very difficult for us to generate new signing keys, due to offline requirement of key storage and bars to international travel during pandemic.

I hope we could get this into either 21.04 or 21.10, with a goal to have this solid by 22.04. Does that meet your project timelines for this?