shim 15.7 and key rotation woes
Julian Andres Klode
julian.klode at canonical.com
Thu Jan 19 15:34:49 UTC 2023
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
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
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
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
1. Potential for a lot of annoyance
2. I expect enterprisy folks to run stuff like dpkg -V and flag that
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
Hence why I am leaning towards 3.
More information about the ubuntu-devel