Skip to content

auto-mark new VMs for Secure Boot certificate update on boot#7155

Open
stephenchengCloud wants to merge 2 commits into
xapi-project:masterfrom
stephenchengCloud:private/stephenche/CP-313372
Open

auto-mark new VMs for Secure Boot certificate update on boot#7155
stephenchengCloud wants to merge 2 commits into
xapi-project:masterfrom
stephenchengCloud:private/stephenche/CP-313372

Conversation

@stephenchengCloud

Copy link
Copy Markdown
Collaborator

Microsoft's 2011 Secure Boot certificates expire between June and October 2026. XenServer already has a remediation workflow (the per-VM field VM.secureboot_certificates_state plus VM.update_secureboot_certificates_on_boot) that lets an admin mark a VM so its Secure Boot certificates are replaced on the next (re)boot. CVAD MCS (Citrix Machine Creation Services) stores a copy of the VM NVRAM per catalog and supplies it on VM.create; catalogs built from 2011-only VMs therefore keep creating 2011-only VMs, which can fail to boot once the disk relies on 2023 certs. This feature lets a pool opt in to having xapi auto-mark such freshly created VMs so the certs are updated on first boot.

Tested:

  1. Mock varstore-nvram-certcheck to always return update_required.
  2. Use VM.create to trigger the logic:
Test A (flag=true):  state = update_on_boot  (expect update_on_boot)
Test B (flag=false): state = ok  (expect ok)

…date on boot

1. Add a pool-level boolean Pool.auto_update_vm_secureboot_certificates
(RW, default false).

This is the opt-in switch for automatically updating expiring Secure Boot
certificates on newly created VMs; it defaults to disabled so xapi never
modifies VM NVRAM unless the admin opts in.

2. When the pool option auto_update_vm_secureboot_certificates is enabled,
VM.create now inspects the NVRAM supplied at creation time (e.g. by MCS)
and, if the Secure Boot certificates are due to expire, sets the VM's
secureboot_certificates_state to update_on_boot so the certificates are
refreshed on the next boot.

check_secureboot_certificates_state returns ok cheaply when the NVRAM has
no EFI variables (e.g. BIOS VMs), so no external check is run in that
case. The behaviour is gated on the pool opt-in, so default behaviour is
unchanged.

Signed-off-by: Stephen Cheng <stephen.cheng@citrix.com>
Signed-off-by: Stephen Cheng <stephen.cheng@citrix.com>
@stephenchengCloud stephenchengCloud force-pushed the private/stephenche/CP-313372 branch from dd208c0 to a791bf2 Compare July 1, 2026 04:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant