Skip to content

Commit 9d722a9

Browse files
committed
Add Secure Boot change announcement and instructions
Signed-off-by: Tu Dinh <[email protected]>
1 parent 15c80a8 commit 9d722a9

File tree

1 file changed

+77
-10
lines changed

1 file changed

+77
-10
lines changed

docs/guides/guest-UEFI-Secure-Boot.md

Lines changed: 77 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -4,20 +4,62 @@ How to configure UEFI Secure boot?
44

55
Enabling UEFI Secure Boot for guests ensures that XCP-ng VMs will only execute trusted binaries at boot. In practice, these are the binaries released by the operating system (OS) vendor for the OS running in the VM (Microsoft Windows, Debian, RHEL, Alpine, etc.).
66

7+
## Upcoming changes in Secure Boot
8+
9+
The default Secure Boot keys in XCP-ng are changing.
10+
11+
Previously, XCP-ng only shipped with the PK included by default; Secure Boot variables had to be installed using `secureboot-certs`.
12+
New versions of XCP-ng's `varstored` (from version 1.2.0-2.4 and newer) now come with a complete set of Secure Boot variables (PK/KEK/db/dbx) by default, meaning that guest Secure Boot will now work for new VMs without needing further pool configuration.
13+
14+
### What this change means for you
15+
16+
You will not be affected in most cases.
17+
18+
* Existing VMs will not be affected unless you use the [Propagate certificates](#propagate-pool-certificates-to-a-vm) feature in Xen Orchestra (which has always had the effect of resetting VM Secure Boot variables to that of the pool).
19+
* If you followed our previous guides and used `secureboot-certs install` to install the default Secure Boot variables into your pool, these variables will not be changed.
20+
21+
Here are the changes:
22+
23+
* If you haven't used `secureboot-certs install` on your pool, your pool now supports guest Secure Boot by default.
24+
25+
* Our defaults now include the 2023 Microsoft KEK and db certificates, ensuring Windows compatibility beyond 2026 (which is when the previous 2011 certificates expire).
26+
27+
In particular, the 2023 Microsoft KEK certificate is needed for guest-initiated security updates to the db and dbx variables.
28+
29+
* If you have used `secureboot-certs install` on your pool before, install these certificates manually by running this command again.
30+
31+
* After updating the pool variables, you can add this certificate to existing VMs using the [Propagate certificates](#propagate-pool-certificates-to-a-vm) procedure.
32+
33+
:warning: This will change the Secure Boot vTPM measurements. If you depend on these measurements (e.g. BitLocker with TPM protector), you must follow the [Preparing for Secure Boot Variable Changes](#preparing-for-secure-boot-variable-changes) procedure.
34+
35+
* **Newly created VMs** will change their behavior with Secure Boot enabled, running on pools where `secureboot-certs install` have not been executed.
36+
Previously, these VMs would execute revoked UEFI binaries even with Secure Boot enabled (due to an empty dbx variable); however, going forward, revoked UEFI binaries (e.g. from an outdated media) will no longer boot on such VMs with Secure Boot enabled.
37+
Note that this does not apply to VMs cloned from another already-installed VM or template.
38+
39+
To continue booting outdated media on these VMs, you can either:
40+
41+
* Disable Secure Boot;
42+
* Or, if the VM has booted at least once, erase its dbx variable with the command `varstore-rm <vm uuid> d719b2cb-3d3a-4596-a3bc-dad00e67656f dbx`. Once your VM has completed installing, it should be able to manage its own Secure Boot variables (db/dbx) via its update mechanism.
43+
744
## Requirements
845

946
* XCP-ng >= 8.2.1.
1047
* UEFI Secure Boot Certificates installed on the pool (this is detailed below).
1148
* A UEFI guest VM.
12-
* For Windows, ensure the VM has at least 2 vCPUs.
1349

1450
:::warning
1551
Until we can re-sign XCP-ng's PV drivers for Windows, you will need the PV drivers from XenServer before enabling Secure Boot for a Windows VM. See [Setup Secure Boot for Windows VMs](#setup-secure-boot-for-windows-vms).
1652
:::
1753

1854
Note: it's not necessary that the XCP-ng host boots in UEFI mode for Secure Boot to be enabled on VMs.
1955

20-
## Quick Start
56+
## 8.3 with varstored >= 1.2.0-2.4
57+
58+
Secure Boot is ready to use on new VMs without extra configuration. Simply activate Secure Boot on your VMs, and they will be provided with an appropriate set of default Secure Boot variables.
59+
60+
We will keep updating the default Secure Boot variables with future updates from Microsoft. If you don't want this behavior, you can lock in these variables by using the [Install the Default UEFI Certificates](#install-the-default-uefi-certificates) procedure.
61+
62+
## Quick Start (8.2.1 and 8.3 with varstored < 1.2.0-2.4)
2163

2264
We believe that reading this guide will provide you with useful knowledge about the way Guest Secure Boot is handled in XCP-ng, and let you avoid mistakes.
2365

@@ -91,24 +133,46 @@ For custom certificates (advanced use), see [Install Custom UEFI Certificates](#
91133

92134
### Install the Default UEFI Certificates
93135

136+
:::info
137+
This procedure is not necessary if you're using varstored 1.2.0-2.4 and newer. However, you can use the procedure anyway to lock in the default variables per pool and avoid further default changes.
138+
:::
139+
94140
`secureboot-certs` supports installing a default set of certificates across the pool.
95141

96142
Except the `PK` key which is already provided by XCP-ng, all certificates are downloaded from official sources (`microsoft.com` and `uefi.org`).
97143

98144
The default certificates are sourced as follows:
99145

146+
**With varstored < 1.2.0-2.4:**
147+
100148
| Certificate | Source | CLI Arg |
101149
|-------------|-------------------------------------------------------------------------------------------------------------------|-----------|
102150
| PK | Provided by XCP-ng, already present on disk. | `default` |
103-
| KEK | [Microsoft Corporation UEFI KEK CA 2011](https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt) | `default` |
151+
| KEK | [Microsoft Corporation KEK CA 2011](https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt) | `default` |
104152
| db | [Microsoft Corporation UEFI CA 2011](https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt) and [Microsoft Windows Production PCA 2011](https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt) | `default` |
105153
| dbx | [UEFI Revocation List](https://uefi.org/sites/default/files/resources/dbxupdate_x64.bin) | `latest` |
106154

107-
To install these certificates from the command line interface:
155+
**With varstored >= 1.2.0-2.4:**
156+
157+
All keys are built into varstored-tools and present on disk. There's no need to configure them except for custom Secure Boot scenarios.
158+
159+
Certificate and revocation lists provided by [microsoft/secureboot_objects](https://github.com/microsoft/secureboot_objects).
160+
161+
| Certificate | Source | CLI Arg |
162+
|-------------|-------------------------------------------------------------------------------------------------------------------|-----------|
163+
| PK | Provided by XCP-ng. | `default` |
164+
| KEK | Microsoft Corporation KEK CA 2011 and Microsoft Corporation KEK 2K CA 2023 | `default` |
165+
| db | Microsoft Windows Production PCA 2011, Windows UEFI CA 2023, Microsoft Corporation UEFI CA 2011, Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 | `default` |
166+
| dbx | Image hashes provided by microsoft/secureboot_objects (can specify `latest` to download latest dbx instead) | `default` |
167+
168+
To install these variables from the command line interface:
108169

109170
```
110-
# Download and install PK/KEK/db/dbx certificates
171+
# Download and install PK/KEK/db/dbx certificates (varstored < 1.2.0-2.4)
111172
secureboot-certs install default default default latest
173+
174+
# Reinstall built-in PK/KEK/db/dbx variables (varstored >= 1.2.0-2.4)
175+
secureboot-certs install default default default default
112176
```
113177

114178
This can be shortened to:
@@ -162,20 +226,23 @@ Advanced use, not needed by most users.
162226
For example, to install a custom PK you may do the following:
163227
164228
```
165-
# Enroll it, along with the default certificates, with secureboot-certs
166-
secureboot-certs install PK.cer default default latest
229+
# Enroll a custom PK along with the default KEK/db/dbx
230+
secureboot-certs install PK.cer
167231
```
168232
169-
The same procedure may be used to install custom KEK, db, or dbx certs.
233+
The same procedure may be used to install custom KEK, db, or dbx variables.
170234
171235
To use multiple certificates in one variable (that is, have multiple certificates stored as a single KEK, db, or dbx), the certs must be packaged together into a .auth file, see [Use two or more certificates for a Secure Boot variable](#use-two-or-more-certificates-for-a-secure-boot-variable). Note that multiple certificates in the PK is not supported. If an auth file with multiple certs is loaded as the PK, only the first one found will be used.
172236
173237
Note that the virtual firmware, as is allowed by the specification, does not mandate that these default certificates be signed by their parent (i.e., the KEK doesn't need to be signed by PK) if they're installed via `secureboot-certs`. This verification *does* occur, however, when trying to enroll new certificates from inside the guest after boot. This is designed to give the host administrator full control over the certificates from the control domain.
174238
175-
If necessary for your use case you may omit the `dbx` entirely. Note that this basically **renders secure boot useless** from a security perspective, as any binary signed with a revoked certificate will still pass Secure Boot checks! This may be done by using the following command:
239+
You can also omit the dbx variable entirely.
240+
This is the most compatible option for old installation media that may not include the newest Secure Boot fixes.
241+
Once installed, the guest can still update the dbx variable on its own to revoke vulnerable bootloaders as long as the default KEK is included.
242+
Omitting the dbx variable can be done using the following command:
176243
177244
```
178-
# Download and install PK/KEK/db certificates, omit the dbx
245+
# Install default PK/KEK/db variables, omit the dbx
179246
secureboot-certs install default default default none
180247
```
181248

0 commit comments

Comments
 (0)