Following up on my recent work adding Intel TDX support to Alioth, I am thrilled to announce another major milestone for the project: full UEFI support. This enables Alioth to boot standard Linux distributions seamlessly, taking us one step closer to running fully featured confidential virtual machines.
AVMF: Alioth Virtual Machine Firmware
To achieve this, I forked EDK2/OVMF (which is traditionally used for QEMU) to create a new, UEFI-compatible firmware specifically tailored for Alioth. I’m calling it AVMF (Alioth Virtual Machine Firmware).
The code for AVMF is available on GitHub at https://github.com/Lencerf/edk2 on the feat/alioth/avmf branch. Here is a summary of the core changes made to EDK2 to support Alioth:
- Forked QEMU’s OVMF: Created a new
AliothPkgby copying and adapting the OVMF configuration (.dscand.fdffiles). - Added Alioth-Specific Libraries: Implemented new
AcpiTimerLibandResetSystemLibinstances tailored for Alioth’s hardware model. - Platform Initialization Updates: Modified memory detection and platform initialization code to recognize the PCI Host Bridge Device ID of Alioth. This includes configuring the correct 32-bit MMIO base and size, setting up PCI IO port space, and skipping QEMU-specific hardware routines.
Upgrading Alioth for UEFI
On the hypervisor side, supporting a complex firmware environment like UEFI required adding a few more emulated devices and ironing out several bugs. I’ve made significant improvements to the device model, including:
- New Emulated Devices: Added a
fw_dbgdevice specifically for capturing firmware logs #426, an emulated CMOS for x86 #421, and an ACPI Power Management timer #419. - fw_cfg Enhancements: Added CPU count and memory size to
fw_cfg#423 so the firmware can dynamically read the VM configuration instead of relying on hardcoded platform initialization. - MMIO and ACPI Fixes: Fixed MMIO to properly return all-ones when reading unmapped addresses #422 (a common behavior firmware expects) and fixed an issue with clearing ACPI table checksums before recalculation #417.
- AMD-SNP related Fixes: Removed unsupported CPUID features #424 and fixed unknown page descriptors as zero pages for AMD-SNP #425.
AI-Assisted Firmware Development
One of the most exciting aspects of developing AVMF was the workflow. I used Gemini AI to assist with the firmware development, guiding it with a comprehensive prompt file called project.md. This prompt contained the project goals, repository paths, build instructions, and tips on the architectural differences between QEMU and Alioth’s hardware models.
I have to say, it was amazingly effective. Once I spent the time to properly set up the development environment and clearly define the context and goals in project.md, Gemini was able to navigate the complex EDK2 codebase, strip out QEMU-specific dependencies, and help construct the new AliothPkg almost seamlessly.
The Result: Booting Confidential Linux
The combination of AVMF and the updated Alioth VMM is a massive leap forward. With AVMF, we can now successfully boot confidential VMs using both AMD-SNP and Intel-TDX.
I have successfully tested booting Fedora Linux 43 as a confidential guest, proving that the firmware and device model are capable of handling a modern, unmodified OS boot process.
However, I observed some random crashes of the firmware when rebooting the VM, so more efforts are needed to polish the firmware to a truly robust state.
This is an exciting step for the Alioth project. Stay tuned for more updates as I continue to refine the hypervisor and explore more advanced confidential computing features!