[Bug 2146560] [NEW] [FFe + SRU] edk2: Introduce FirmwareSecvarUpdater for MS 2023 CA rollout

Mate Kukri 2146560 at bugs.launchpad.net
Fri Mar 27 13:34:55 UTC 2026 

Public bug reported:

[ Impact ]

 * Every OVMF/AAVMF virtual machine with Secure Boot enabled is
impacted.

 * VM variable stores are snapshotted at creation time. Existing VMs only
   have Microsoft's 2011 Secure Boot CAs in their KEK and db. These CAs
   expire in 2026 and Microsoft is transitioning to signing exclusively
   with 2023 replacements. Without the 2023 CAs, existing VMs will be
   unable to verify future shim, GRUB, and kernel updates.

 * On physical hardware, db and KEK updates are deployed via fwupd using
   authenticated variable writes signed by the appropriate keys. This is
   not possible for OVMF/AAVMF because the PK private key was intentionally
   destroyed at variable template generation time.

 * A DXE driver (FirmwareSecvarUpdater) is added to the firmware CODE
   volume. It runs at boot, checks for 2011 CAs without their 2023
   replacements, and appends the missing certificates using EDK2's Custom
   Mode mechanism. A version variable prevents re-running on subsequent
   boots and allows users to remove the added certificates if desired.

[ Test Plan ]

 * Build-time and autopkgtest integration tests are included:

   1. Boot a VM with only 2011 CAs enrolled, verify all 2023 CAs are
      appended to KEK and db.

   2. After the driver has run, strip the 2023 CAs and reboot. Verify
      the version guard prevents re-adding them.

   3. Same as (1) for AAVMF (aarch64).

[ Where problems could occur ]

 * If the driver encounters an error (e.g. variable store full), it fails
   gracefully without preventing boot and retries on the next boot.

 * The driver only acts on variable stores containing the expected 2011
   CAs.

 * If a user removes the 2023 CAs after the driver has run, the version
   guard ensures they are not re-added.

[ Other Info ]

 * Certificate mappings:
   - KEK: MS KEK CA 2011 -> MS KEK 2K CA 2023
   - db: Windows Production PCA 2011 -> Windows UEFI CA 2023
   - db: MS UEFI CA 2011 -> MS UEFI CA 2023 + MS Option ROM CA 2023

 * The driver is added to all virtual platform builds with Secure Boot
   support. Future certificate rotations require only adding rows to the
   update rules table and bumping the version constant.

** Affects: edk2 (Ubuntu)
     Importance: High
     Assignee: Mate Kukri (mkukri)
         Status: In Progress

** Changed in: edk2 (Ubuntu)
     Assignee: (unassigned) => Mate Kukri (mkukri)

** Changed in: edk2 (Ubuntu)
   Importance: Undecided => High

** Changed in: edk2 (Ubuntu)
       Status: New => In Progress

** Description changed:

  [ Impact ]
  
-  * Every OVMF/AAVMF virtual machine with Secure Boot enabled is
+  * Every OVMF/AAVMF virtual machine with Secure Boot enabled is
  impacted.
  
-  * VM variable stores are snapshotted at creation time. Existing VMs only
-    have Microsoft's 2011 Secure Boot CAs in their KEK and db. These CAs
-    expire in 2026 and Microsoft is transitioning to signing exclusively
-    with 2023 replacements. Without the 2023 CAs, existing VMs will be
-    unable to verify future shim, GRUB, and kernel updates.
+  * VM variable stores are snapshotted at creation time. Existing VMs only
+    have Microsoft's 2011 Secure Boot CAs in their KEK and db. These CAs
+    expire in 2026 and Microsoft is transitioning to signing exclusively
+    with 2023 replacements. Without the 2023 CAs, existing VMs will be
+    unable to verify future shim, GRUB, and kernel updates.
  
-  * On physical hardware, db and KEK updates are deployed via fwupd using
-    authenticated variable writes signed by the appropriate keys. This is
-    not possible for OVMF/AAVMF because the PK private key was intentionally
-    destroyed at variable template generation time.
+  * On physical hardware, db and KEK updates are deployed via fwupd using
+    authenticated variable writes signed by the appropriate keys. This is
+    not possible for OVMF/AAVMF because the PK private key was intentionally
+    destroyed at variable template generation time.
  
-  * A DXE driver (FirmwareSecvarUpdater) is added to the firmware CODE
-    volume. It runs at boot, checks for 2011 CAs without their 2023
-    replacements, and appends the missing certificates using EDK2's Custom
-    Mode mechanism. A version variable prevents re-running on subsequent
-    boots and allows users to remove the added certificates if desired.
+  * A DXE driver (FirmwareSecvarUpdater) is added to the firmware CODE
+    volume. It runs at boot, checks for 2011 CAs without their 2023
+    replacements, and appends the missing certificates using EDK2's Custom
+    Mode mechanism. A version variable prevents re-running on subsequent
+    boots and allows users to remove the added certificates if desired.
  
  [ Test Plan ]
  
-  * Build-time and autopkgtest integration tests are included:
+  * Build-time and autopkgtest integration tests are included:
  
-    1. Boot a VM with only 2011 CAs enrolled, verify all 2023 CAs are
-       appended to KEK and db.
+    1. Boot a VM with only 2011 CAs enrolled, verify all 2023 CAs are
+       appended to KEK and db.
  
-    2. After the driver has run, strip the 2023 CAs and reboot. Verify
-       the version guard prevents re-adding them.
+    2. After the driver has run, strip the 2023 CAs and reboot. Verify
+       the version guard prevents re-adding them.
  
-    3. Same as (1) for AAVMF (aarch64).
+    3. Same as (1) for AAVMF (aarch64).
  
  [ Where problems could occur ]
  
-  * If the driver encounters an error (e.g. variable store full), it fails
-    gracefully without preventing boot and retries on the next boot.
+  * If the driver encounters an error (e.g. variable store full), it fails
+    gracefully without preventing boot and retries on the next boot.
  
-  * The driver only acts on variable stores containing the expected 2011
-    CAs. Custom Secure Boot configurations are not modified.
+  * The driver only acts on variable stores containing the expected 2011
+    CAs.
  
-  * If a user removes the 2023 CAs after the driver has run, the version
-    guard ensures they are not re-added.
+  * If a user removes the 2023 CAs after the driver has run, the version
+    guard ensures they are not re-added.
  
  [ Other Info ]
  
-  * Certificate mappings:
-    - KEK: MS KEK CA 2011 -> MS KEK 2K CA 2023
-    - db: Windows Production PCA 2011 -> Windows UEFI CA 2023
-    - db: MS UEFI CA 2011 -> MS UEFI CA 2023 + MS Option ROM CA 2023
+  * Certificate mappings:
+    - KEK: MS KEK CA 2011 -> MS KEK 2K CA 2023
+    - db: Windows Production PCA 2011 -> Windows UEFI CA 2023
+    - db: MS UEFI CA 2011 -> MS UEFI CA 2023 + MS Option ROM CA 2023
  
-  * The driver is added to all virtual platform builds with Secure Boot
-    support. Future certificate rotations require only adding rows to the
-    update rules table and bumping the version constant.
+  * The driver is added to all virtual platform builds with Secure Boot
+    support. Future certificate rotations require only adding rows to the
+    update rules table and bumping the version constant.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to edk2 in Ubuntu.
https://bugs.launchpad.net/bugs/2146560

Title:
  [FFe + SRU] edk2: Introduce FirmwareSecvarUpdater for MS 2023 CA
  rollout

Status in edk2 package in Ubuntu:
  In Progress

Bug description:
  [ Impact ]

   * Every OVMF/AAVMF virtual machine with Secure Boot enabled is
  impacted.

   * VM variable stores are snapshotted at creation time. Existing VMs only
     have Microsoft's 2011 Secure Boot CAs in their KEK and db. These CAs
     expire in 2026 and Microsoft is transitioning to signing exclusively
     with 2023 replacements. Without the 2023 CAs, existing VMs will be
     unable to verify future shim, GRUB, and kernel updates.

   * On physical hardware, db and KEK updates are deployed via fwupd using
     authenticated variable writes signed by the appropriate keys. This is
     not possible for OVMF/AAVMF because the PK private key was intentionally
     destroyed at variable template generation time.

   * A DXE driver (FirmwareSecvarUpdater) is added to the firmware CODE
     volume. It runs at boot, checks for 2011 CAs without their 2023
     replacements, and appends the missing certificates using EDK2's Custom
     Mode mechanism. A version variable prevents re-running on subsequent
     boots and allows users to remove the added certificates if desired.

  [ Test Plan ]

   * Build-time and autopkgtest integration tests are included:

     1. Boot a VM with only 2011 CAs enrolled, verify all 2023 CAs are
        appended to KEK and db.

     2. After the driver has run, strip the 2023 CAs and reboot. Verify
        the version guard prevents re-adding them.

     3. Same as (1) for AAVMF (aarch64).

  [ Where problems could occur ]

   * If the driver encounters an error (e.g. variable store full), it fails
     gracefully without preventing boot and retries on the next boot.

   * The driver only acts on variable stores containing the expected 2011
     CAs.

   * If a user removes the 2023 CAs after the driver has run, the version
     guard ensures they are not re-added.

  [ Other Info ]

   * Certificate mappings:
     - KEK: MS KEK CA 2011 -> MS KEK 2K CA 2023
     - db: Windows Production PCA 2011 -> Windows UEFI CA 2023
     - db: MS UEFI CA 2011 -> MS UEFI CA 2023 + MS Option ROM CA 2023

   * The driver is added to all virtual platform builds with Secure Boot
     support. Future certificate rotations require only adding rows to the
     update rules table and bumping the version constant.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2146560/+subscriptions

More information about the foundations-bugs mailing list