Guest UEFI Secure Boot
It has always been critical to the mission of the XCP-ng project that the system and its components be free and open. As an open source project, we often collide with other worlds with other licensing arrangements.
XenServer / Citrix Hypervisor systems support Guest UEFI Secure Boot using a package that could be legally distributed, but the source code itself was never released. In order to support UEFI Secure Boot for guest VMs in XCP-ng, as well as maintain a free code base with freely available source code, we set out to rewrite this component of XCP-ng.
UEFI Secure Boot for guests allows you to control what system software gets executed in your guest VMs. By enabling secure boot from dom0 for a guest domain, the firmware implementation in that guest domain will only execute signed binaries and the kernel will only allow signed kernel modules. This means that by following the secure boot instructions for your guest VM distribution and enabling secure boot from dom0 (using `xe`), the effect will be the same as on hardware: only software signed by the distribution will execute.
This feature works for both Windows and Linux.
Why it matters
UEFI Secure Boot prevents a class of attacks in which the attacker modifies the system software, rendering it untrustworthy. In the case of the LoJax vulnerability, the attackers gained system control by writing a malicious firmware module to SPI flash that gets executed on boot. Secure Boot prevents this type of attack because when Secure Boot is enabled, the firmware refuses to execute any system software (firmware modules, bootloaders, kernels, etc...) that is not signed by an authorized signer. In the LoJax case, the malicious module would be unsigned and the attacker would not be able to sign it with out access to the secret keys of the platform owners, and therefore the firmware would reject the malicious module and prevent the attack. It's this exact type of attack that Secure Boot is meant to neutralize.
Trusting your system
Secure boot exists to give users assurance that their system is in a state they expect it to be and will behave how they expect it to behave. On XCP-ng, this feature offers assurance that the system software running as guests is authentic and not compromised. You can trust that your guests are what you expect them to be.
What it gives users
The way this feature is implemented in XCP-ng gives the administrator full control of secure boot in guests, allowing admins to whitelist and blacklist what may/may not execute on their platforms, even in guest context. They may also enable/disable secure boot on a per-vm basis.
How it works
UEFI Secure Boot stores are all keys as UEFI variables accessed via the variables runtime service. The UEFI implementation for XCP-ng guests (OVMF) support the variables service as port IO requests to dom0 in the same way that device emulation works (the low-level infrastructure is described here). This protects secure boot keys by placing them in a memory space that cannot be directly accessed from the guest domain (similar to SMRAM in non-virtualized systems).
Upon boot, if Secure Boot is enabled, OVMF will verify the second stage bootloader (often shim or the windows loader) against the db and dbx database UEFI variables that are stored in dom0. If verification passes, OVMF will launch the bootloader. If verification fails, OVMF will drop into the UEFI shell. On XCP-ng, a secure boot failure triggers a XAPI message that can be read from the XAPI DB.
On a Linux-based system, the typical boot flow is from the UEFI implementation, which verifies and starts shim, which verifies and starts grub2, which verifies and starts the Linux kernel. Furthermore, the kernel will verify kernel modules and should have lockdown enabled.
Future Work
The next step would be to deepen the system's guarantee of integrity by implementing secure boot for dom0 and the host, as well as implementing something akin to Linux's lockdown LSM to prevent dom0 modification of Xen.
We've already began the work of supporting Secure Boot for the XCP-ng host platform itself, which requires modification to Xen itself. We will write about that in a future blog.
