Build and use default Secure Boot variable files

[dinhngtu]

Changelog:

• Add gen-dbx.py
• Add self-signed PK.auth blob
• Generate {KEK,db,dbx}.auth using gen-dbx.py
• Update secureboot-certs to take builtin KEK/db/dbx
• Update Secure Boot certs from microsoft/secureboot_objects@3f69ef4

⚠️ Note that the self-signed KEK (originally generated by secureboot-certs) is no longer generated or installed. {KEK,db,dbx}.auth are also unsigned.

secureboot-certs retains the option to download the latest dbx.

---

Work Item Reference

If this change is related to a Vates internal task or issue, please provide a work item reference. Otherwise, leave this blank.

XCPNG-701

---

Why should this change be accepted as an update to XCP-ng?

Explain the motivation, problem being solved, or benefit to users or maintainers.

1. The existing Secure Boot authorities are expiring (https://techcommunity.microsoft.com/blog/windows-itpro-blog/act-now-secure-boot-certificates-expire-in-june-2026/4426856) and it's time to deliver an update.
2. The current PK/KEK are unstable and generated at build time. We have no way of actually using them.
3. I want to enable Secure Boot by default without requiring manual steps.

---

Release Notes

Explain the change for users

Write a user-facing explanation which will serve as a basis for public announcements.
Good release notes explain what changes, who is concerned, and how it affects them. It's not a technical changelog.

• Update pool-default UEFI Secure Boot variables with Microsoft 2023 certificates
• Enable Secure Boot by default on pools with varstored >= 1.2.0-2.4

Do users or support need to be aware of anything specific related to the update?

Any manual steps, changes to default behavior, compatibility issues, etc.

• Yes
• No

If yes, provide details.

Already detailed at xcp-ng/xcp-ng-org#328

---

Testing and regression avoidance

What tests have you done?

1. Regarding the change itself.

Tested Secure Boot enabled with propagation; new Server 2022 installed from CD; and Ubuntu Server 24.04.1 booted from CD. TPM measurements of SB variables were dumped and compared after installation/variable update.

2. Regarding potential regressions.

See above.

What tests in current test suites cover this change?

1. Regarding the change itself.

tests/uefi_sb -m windows_vm
tests/uefi_sb -m 'not windows_vm and not hostA2' -k 'not test_vm_import_restores_certs and not test_host_certificates_updated_after_join'

2. Regarding potential regressions.

main-multi-*,sb_*,vtpm

What tests were or will be added to CI for this change? If none, explain why.

1. Regarding the change itself.

xcp-ng/xcp-ng-tests#277

2. To ensure there are no regressions.

None. Since I'm not changing varstored's operation I think current tests are adequate.

What other tests should reviewers or testers perform (after the build)?

1. Regarding the change itself.

See manual tests above (if needed).

2. Regarding potential regressions.

See above.

---

Documentation

Should existing documentation be updated, or new documentation be added?

• Yes
• No

If yes, explain what needs to be updated or added, and where. If no, explain why.

xcp-ng/xcp-ng-org#328

---

Xen Orchestra Impact

Does this affect existing features in Xen Orchestra, or add features that could be useful for Xen Orchestra?

• Yes
• No

If yes, describe which features and how.

N/A

[stormi]

Note that there are two layers of UEFI certificates in XAPI. The default ones directly read from /usr, and the custom ones. secureboot-certs sets the custom ones. I don't think your modifications to that script take this into account.

[dinhngtu]

My understanding is that since I've removed the cert downloading code, when default is selected for a variable, secureboot-certs only needs to copy its contents from /usr/share/varstored, which should already contain the prebaked certs.

[dinhngtu]

I've updated the DBX generation script and spec files for generating our own dbx.auth.

Note that there are two ways to generate our dbx (see the microsoft/secureboot_objects wiki):

1. Using hashes found in the "images" key only, which is more compatible (blocks fewer media) but doesn't block all files related to CVE-2023-24932;
2. Using hashes + secure version numbers (SVNs) + outright block the "Microsoft Windows Production PCA 2011" signer, which will block every old Windows media from working.

I've chosen the first approach in my PR, but it can be easily changed if needed.

[dinhngtu]

Should I implement the PK changes as discussed?

[dinhngtu]

Changes:

• Build KEK and db with our own gen-dbx.py instead of create-auth.
• Don't sign the generated auth variable blobs any more.
• Remove the three create-auth patches that are no longer needed.

Now the PK changes can be easily integrated.

[dinhngtu]

Changes:

• Implemented stable PK as discussed.
• Used our own GUID and timestamp instead of Microsoft's.

I'll need to test manually first.

(Also, please squash, the history is not clean for a straight merge)

[dinhngtu]

Tested with pool state cleared, then SB vars propagated to a new cloned Server 2022 VM: https://paste.vates.tech/?6ebab242eb9fcacf#AE474uTGjG6JCMUU6QKdUAauSaF4LNNJ1kzjhm9BZ8R4

After secureboot-certs install and repropagation: https://paste.vates.tech/?d0e321b00468a974#EAM1B5sMg7QTaWR8XJhsGLjZsVza5kY8iDFyfasYRSC3

[dinhngtu]

Scratch build: https://koji.xcp-ng.org/taskinfo?taskID=89110 https://koji.xcp-ng.org/taskinfo?taskID=89112

[dinhngtu]

Due to the order where Secure Boot variables are set during initial setup (https://github.com/xapi-project/varstored/blob/53277ffa62ab0021e8dac9faf5908566d4ce9bc7/handler.c#L170-L179), for things to work correctly if the VM has Secure Boot enabled during initial setup, the PK (and no other variable) will require a signed auth blob for pool-level installation.

[dinhngtu]

Added self-signed PK blob. Works with propagation; new Server 2022 installed from CD; and Ubuntu Server 24.04.1 booted from CD.

Variable logs: https://paste.vates.tech/?0fce36801736b2b5#8j3i7jmZTVGFwMqCwEyenBZ2Um1nhJa7HPNCV3s6qbTE

Ubuntu:

[stormi]

Is the name appropriate? It suggests it is designed to build dbx but we also use it for KEK and db now.

[dinhngtu]

Renamed

[stormi]

Koji build to v8.3-incoming: https://koji.xcp-ng.org/taskinfo?taskID=90790