RFC: Revocation Delivery Proposal

Problem:

Revocations beyond dbx require updating non-authenticated boot
services variables. Unlike the signed dbx blobs that can be applied at
runtime independently from updating the first stage bootloader, these
revocations were initially built into shim as an optional “latest” and
automatic payload. These payloads exist for both SBAT (shim based
Linux distros) and SKU Si (bootmgr based Windows distros). Binaries
from both ecosystems can be used to attack both ecosystems on typical
systems that trust both the UEFI and Window CA.

While automatically putting a system into the most secure state
possible by applying the latest revocation quickly is desirable, it
carries a very real risk of preventing a legitimately installed system
from booting. These scenarios are fall-back after and update and dual
boot. While shim now supports picking up the revocation payload from a
separate binary blob that can be updated independently from shim, the
policy for deploying this blob will depend on how a particular system
is being managed, similar to how dbx updates are being deployed.

Current state:

Most Linux distros are able to deliver a built-in automatic SBAT
revocation that revokes binaries that are roughly 1 year old or
older. Ones that are not have shifted to an empty automatic SBAT
payload. All Linux distros deliver a shim that allows an opt-in SKU Si
revocation to be applied, none of them do this automatically.

Windows currently only applies SKU Si revocations based on a manual
opt-in and does not deliver SBAT revocations.

Proposal:

Systems should automatically apply the most recent payload for the
ecosystem they are not in, unless the other binary is seen as an
active bootloader before the one being booted on the boot list. (XXX:
This seems awfully complex to protect dual boot systems that already
have terrible compatibility. - Still this should be handled the same
way by shim and bootmgr)

Systems that potentially need to support falling back to an older
version of the same OS will need to manage revocations either manually
or as part of an automated orchestration that drives the update /
fallback process above the OS instance.

Solution:

Deliver revocations in a separate package that has dependencies that
prevent it from being installed on an OS that it would revoke. This
package also delivers previous revocations in cumulative blobs. Which
revocation is put in place for shim to install can be configured as:

1. Apply the most recent revocation that does not revoke the OS being
   updated to.

2. Apply the most recent revocation that does not revoke the OS being
   updated from.

3. Apply the most recent revocation that does not revoke the OS
   installed at an alternate, supplied, mount location.

4. Manually lock revocations at a specific level.

Defaulting to (2) where (2) is effectively (1) for a fresh install.

Optional dual boot friendly packages:

Deliver an alternate stream of these packages that do not deliver SKU
Si revocations for dual boot systems that an admin can opt into under
the assumption that they are sometimes booting Windows and want
Windows to manage its own revocations.

Rejected Proposal:

Record the hash of in-use bootloaders and add them to an SBAT specific
exception list that allows only that binary to elude SBAT based
revocation at the same time as applying the revocation.

Pros:
- This would protect from automated attacks using a binary that
doesn't precisely match the one listed by hash.

Cons:
- The fallback OS version could be updated to an intermediate
version.
- Complex to apply correctly without risking a roll-back attack.
shim would need to examine the binary and determine that it matches
the sbat level that's being revoked at the same time. This creates
a new, non-trivial attack surface.

Orthogonal concept:

Generic UEFI CA signed revocation.efi binaries could be delivered to fwupd
and installed via that framework.