Display accurate Secure Boot status and allow to fix a VM's UEFI certs

[stormi]

Context

Secureboot support in XenServer and XCP-ng is not as simple as it would seem at first sight. Setting platform.secureboot to True is merely a wish, but depending on the situation, this may end in:

• A booted system with Secure Boot enforced, as wanted.
• A UEFI shell, because the binaries to boot are not signed with a supported key.
• A UEFI shell, because the VM's NVRAM doesn't contain the necessary certificates to verify the signed binaries. Common situation on XCP-ng until you installed certificates to the pool, then to all VMs having already booted at least once.
• A booted system with Secure Boot disabled. Yes, no kidding. This happens if the VM is in setup mode, regardless of XAPI's VM parameter. It is not supposed to happen without the user explicitly asking for it, but bugs may happen as we just found out in XCP-ng 8.3, so let's cover this case too.
• Other specific situations

Contrarily to XCP-ng 8.2, XCP-ng 8.3 will not auto-install the necessary SecureBoot certificates to VMs which have already been booted once without certificates. This could potentially leave many VMs either unbootable, or bootable with SecureBoot actually disabled and thus a false sense of security.

We need to add information about this to Xen Orchestra, to help users understand why a VM won't boot or we warned that SecureBoot is not enabled despite they may think it is. We added new endpoints in XAPI for XCP-ng 8.3 (not in XenServer 8.3, though, because it was released before we could contribute the changes).

We also need to offer them a way to truly enable SecureBoot for their VM.

Specifications

On XCP-ng/XenServer >= 8.3 (we don't cover 8.2 because 1. there are less potential issues for users and 2. we won't backport the new API endpoints).

Display secureboot status information in the VM, when its firmware is uefi. A. "SecureBoot not enforced" B. "SecureBoot enforced, pending first boot" C. "SecureBoot enforced" D. "SecureBoot enforced, but no dbx present" => If host is XCP-ng, link to https://docs.xcp-ng.org/guides/guest-UEFI-Secure-Boot/#troubleshoot-guest-secure-boot-issues E. ":warning: SecureBoot wanted, but disabled due to the VM being in UEFI setup mode" => If host is XCP-ng, link to https://docs.xcp-ng.org/guides/guest-UEFI-Secure-Boot/#troubleshoot-guest-secure-boot-issues F. ":warning: SecureBoot wanted, but some EFI certificates are missing" => If host is XCP-ng, link to https://docs.xcp-ng.org/guides/guest-UEFI-Secure-Boot/#troubleshoot-guest-secure-boot-issues

This should be displayed both in the general VM view, because it's an important piece of information, and also below the Secure Boot switch in the Advanced view of the VM, updated whenever someone changes the switch's state.

On the general VM page, this information should be updated whenever the VM changes state.

To determine which case the VM is in, call VM.get_secureboot_readiness (new API being implemented in XCP-ng 8.3):

• disabled => A
• first_boot => B
• ready => C
• ready_no_dbx => D
• setup_mode => E
• certs_incomplete => F

In addition to the information display, we need a button to cause users to propagate certificates from the pool to the VM which has bad or no certificates.

• Location of the button: under the "Secure Boot" switch.
• Button Label: Copy the pool's default UEFI certificates to the VM
• Displayed (or enabled) only for UEFI VMs. If just disabled, add an information stating why.
• If pool.get_guest_secureboot_readiness is NOT_READY, disable the button, and add a warning next to it or under it, stating "This pool was not setup for Guest UEFI SecureBoot yet" + link to https://docs.xcp-ng.org/guides/guest-UEFI-Secure-Boot/#configure-the-pool
• When clicked: if VM.get_secureboot_readiness is one of first_boot, setup_mode, certs_incomplete, don't ask for confirmation. Otherwise, ask: "This will overwrite the VM's UEFI certificates with certificates defined at the pool level. Continue?"
• Action when submitted: call XAPI's VM.set_uefi_mode("user")

[stormi]

I realized this morning that the algorithm could maybe also be in XAPI, leaving just the UI and data fetching to XO.

[stormi]

@benjamreis has implemented the algorithm on XAPI side (upstream PR pending review), so this will leave mainly the UI aspects to XO. I'm going to update the specs.

[stormi]

I have updated the specs and suggest we have a short call with the parties involved in this feature to discuss them.

[stormi]

I updated the specs to add the links towards the documentation that I promised.