How to Rebuild the OVMF Firmware Used for VPSBG Measured Boot

OVMF is the open-source UEFI firmware used by QEMU/KVM virtual machines. Before the guest operating system starts, the hypervisor loads this firmware and OVMF follows the configured boot path.

On a normal UEFI VM, that usually means booting from the VM disk. With our VPSBG Measured Boot feature, the uploaded Unified Kernel Image (UKI) is passed directly as the boot payload. In that launch path, both the OVMF firmware and the UKI become inputs to the SEV-SNP measurement.

Because the firmware is part of the measured launch, changing the OVMF binary changes the expected launch measurement as well. For customers building reproducible infrastructure, this is an important detail.

The OVMF binary is one input among several. The uploaded UKI, the kernel command line and launch parameters such as the number of vCPUs, all feed into the final measurement as well. Two otherwise identical VMs with different vCPU counts will produce different measurements.

Publishing the firmware binary alone is useful, but it is not enough for full transparency. A reproducible build process allows you to verify that the file came from a known public source tree, was built with known tooling and matches the expected hash.

Which OVMF Image This Article Covers

This tutorial covers only the OVMF image loaded for VPSBG Measured Boot. It is not the firmware used for every UEFI server and it is not the firmware used for standard SEV-SNP when Measured Boot is not enabled.

For standard SEV-SNP, OVMF_SEV_4M.fd is the unmodified Proxmox package binary from pve-edk2-firmware-ovmf. You can pull it from the Proxmox apt repository or rebuild it from the public pve-edk2-firmware source tree.

VPSBG Measured Boot uses a separate OVMF image because the default Proxmox firmware does not support the direct UKI launch path. When a UKI is passed to QEMU with the -kernel argument and kernel-hashes=on is set, the firmware must contain a dedicated metadata area where the hashes of the kernel, initrd and command line are placed so the AMD PSP can include them in the launch measurement. The stock OVMF_SEV_4M.fd is built without this area, so attempting to launch a UKI this way fails before the VM starts.

If you are reproducing a measurement for a server that does not have Measured Boot enabled, this repository is not the right firmware source. In that case, use the default OVMF image from the relevant Proxmox firmware package.

What We Are Publishing

The firmware file, build metadata and rebuild script are available in our public GitHub repository. The repository contains:

The published firmware SHA-256 is:

e4ac90be71f3b455922ebc7106c5630536bf67027de585e34319b0a42fcd716e

The firmware file size is:

4194304 bytes

Source and Build Details

The build uses the AMD SEV OVMF source tree:

https://github.com/AMDESE/ovmf.git

The exact source commit is pinned:

fbe0805b2091393406952e84724188f8c1941837

At the time of validation, this was the commit resolved from the snp-latest branch. The validated build environment is Debian 13 with the following toolchain:

The build target is:

OvmfPkg/AmdSev/AmdSevX64.dsc

The output file is:

/root/AMDSEV/ovmf/Build/AmdSev/RELEASE_GCC5/FV/OVMF.fd

Note: In order to reproduce the exact same SHA-256 hash, the source tree must be checked out to this path:

/root/AMDSEV/ovmf

This is intentional. A small number of EFI modules can embed __FILE__ references even in release builds, which means that changing the checkout path can change the final binary hash.

Because of that, the repository build script uses the same path as our validated build.

Rebuilding The Firmware

Run the rebuild process on a Debian 13 x86_64 system as root. A clean VM or disposable build host is easiest, but not required.

First, clone the repository:

git clone https://github.com/vpsbg/ovmf-measured-boot.git
cd ovmf-measured-boot

You can verify the published firmware file before rebuilding:

sha256sum -c SHA256SUMS

Expected result:

OVMF_SEV_MEASUREDBOOT_4M.fd: OK

Now run the build script:

./build.sh

The script will:

• Install the required Debian build dependencies
• Clone the upstream OVMF source tree into /root/AMDSEV/ovmf
• Check out the pinned source commit
• Initialize the required submodules
• Create an empty placeholder GRUB image so the build skips the GRUB stage
• Build EDK II BaseTools
• Build the AMD SEV OVMF target in release mode
• Compare the final OVMF.fd hash against the expected SHA-256

Note: The empty GRUB placeholder matters for reproducibility. The AMD SEV OVMF target normally embeds a GRUB image used for disk-based boot, but the direct UKI launch path never uses it. Building that stage would also require distribution-specific GRUB modules that are not present on Debian. By creating an empty grub.efi, the script skips this stage entirely and the embedded GRUB image is always identical, which keeps the final firmware hash stable across different build machines.

When the build completes successfully, the final lines should include:

e4ac90be71f3b455922ebc7106c5630536bf67027de585e34319b0a42fcd716e  /root/AMDSEV/ovmf/Build/AmdSev/RELEASE_GCC5/FV/OVMF.fd

Hash matches expected OVMF image. This confirms that the rebuilt firmware matches the OVMF file used by VPSBG for Measured Boot.

OVMF Updates

When the OVMF firmware used for Measured Boot changes, customers need the updated binary, the new SHA-256 hash and the source details in advance so that they can update their expected measurements.

Our intended process is to notify customers with Measured Boot enabled at least 7 days before an OVMF firmware change. The notice will include the updated OVMF binary, SHA-256 hash, source commit and build details.

The new firmware will only be applied when the VM is rebooted. This gives you time to rebuild the firmware, verify the new hash and decide when to reboot into the updated measurement.

We also plan to expose the current firmware hash and related metadata through an API in the future.

Conclusion

Measured Boot is about independent verification. It should not require blind trust in the hosting provider, the firmware binary or the boot process.

By publishing the exact OVMF image and the build process behind it, we want to make our SEV-SNP Measured Boot implementation easier to inspect, reproduce and verify.

For a general introduction to the feature, you can read through our official Measured Boot announcement.