Hi folks, we'll soon be uploading shim 15.7, with 22.04.2 in mind specifically. In this upload we have revoked all currently used keys basically, so we need to do our best to ensure that users do not end up with unbootable systems.
We started resigning all fwupd, grub with the new 2022v1 signing key (note that we only sign grub 2.06 with the new keys, not older versions, hence 2.06 is now in focal and bionic proposed pockets). The kernel team will be signing kernels with the new key shortly. shim-signed will Breaks old fwupd and grub versions. We cannot 'Breaks' the kernels due to various reasons (like there's tons of them and the metapackages don't have a Protected/Important flag set so they are removable by apt). Now how do we enforce that we don't update the shim on the ESP when we don't have kernels trusted by it? One thing is clear: In the maintainer script we need to check which kernels are signed by our CA and see if all of them are in the revoked kernels (if you only have self-signed kernels, or no signed kernels or whatever we don't care about it in the context of this key revocation). Option 1: Fail in preinst This breaks a large apt upgrade in the middle leading to apport errors and unconfigured packages on the system as apt doesn't complete unrelated tasks necessarily. Option 2: Backup and restore In preinst we cp /usr/lib/shim/shimx64.signed /usr/lib/shim/shimx64.signed.bak In postinst, we check if no trusted kernel is around and do cp /usr/lib/shim/shimx64.signed /usr/lib/shim/shimx64.signed.new cp /usr/lib/shim/shimx64.signed.bak /usr/lib/shim/shimx64.signed if a trusted kernel is there, we do rm /usr/lib/shim/shimx64.signed.bak instead. Effectively restoring the previously installed shim. In a kernel postinst.d hook we then do a mv /usr/lib/shim/shimx64.signed.new /usr/lib/shim/shimx64.signed rm /usr/lib/shim/shimx64.signed.bak when installing a trusted kernel. Option 3: Alternatives We ship both the latest and previous shim in shim-signed, install them both as alternatives. If trusted kernels are around, the 'latest' alternative gets priority 100 and the 'previous' gets priority 50; without trusted kernels the priorities are reversed. We then add a kernel postinst.d hook that swaps the priorities and reconfigures shim-signed (installs it to the ESP) when a trusted kernel is being installed. Option 4: Hybrid Basically we install both latest and previous as with alternatives, but manage the symlink ourselves instead of having it configurable as alternatives. Evaluation: 1. Potential for a lot of annoyance 2. I expect enterprisy folks to run stuff like dpkg -V and flag that as intrusion 3. It's a bit whimsical for it to be configurable, but it also going forward will allow us to install both the old and new shims so that UEFI can fallback in case a new shim is broken (a/b boot). 4. Less whimsical than 3 but slightly higher potential of messing this up if we do it ourselves rather than run 2 lines of update-alternatives. Hence why I am leaning towards 3. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
