Re: Design for custom UEFI firmware in PVE

[Fiona Ebner <f.ebner@proxmox.com>]

Hi Christian,

Am 17.04.26 um 6:38 PM schrieb Christian Ludwig:
> there are certain situations when a VM template might bundle its own
> UEFI firmware [1], [2]. TL;DR: Some virtual security appliances like
> SonicWall or Genuscreen, bring their own OVMF implementation.
> Especially in a confidential computing environment, the goal is to not
> trust the hypervisor. It makes perfect sense to not use the firmware
> shipped with Proxmox in that scenario.
> 
> At Genua we plan to bring support for custom UEFI firmware to Proxmox.
> We are new to Proxmox VE development, so bear with us. I want to share
> our design, before we start the effort to implement it.

Thank you for working on this!

> The current UEFI firmware implementation in PVE has two firmware files.
> A host provided code image that ships with each Proxmox release and is
> the same for every VM. And a per-VM writable data store. We plan to
> implement a way to upload and use a custom code image per VM.
> 
> Our design introduces a new 'firmware' content type for directory-based
> storage volumes. The admin can then upload UEFI firmware files there.
> This might even be useful for other types of firmware in the future.
> The firmware file can then be connected to a VM using the VM's QEMU
> config setting, but only if the VM was configured to boot in UEFI mode
> before. If set, the image overrides the -bios QEMU command line option
> for confidential VMs. These do not have a UEFI data store. For
> conventional VMs the option overrides the -pflash0 command line option.

I think the new 'firmware' content type can be fine, but maybe it should
even be 'efi-firmware'. In particular, with the 'images' content type,
we regret overloading it (for VMs and CTs) and there is an unapplied
series [0] that would make the content type <-> volume type mapping 1:1.

Let's clarify the exact usage/workflow of the firmware images:

1. Is it upload and assign the firmware image only to a single VM
(read-write or read-only) and remove it when the VM is gone? So a strict
1:1 mapping, each firmware image ever belongs to a single VM.

2. Is it upload and copy the firmware image for each VM before first use
(read-write or read-only)? So a loose 1:1 mapping. While the original
firmware image is 1:n, its copies are strictly 1:1.

3. Is it upload and use by multiple VMs (I assume read-only, since
read-write is probably too outlandish here)? So a proper 1:n mapping
between firmware image and VMs.

Case 1 would behave similar to 'images', but with upload support.
Case 2 would behave similar to 'import'+'images'.
Case 3 would behave similar to 'iso'.

To be clear, this is not a suggestion to use those content types, just
to give some orientation with what we already have. I think in all three
cases we can have 'efi-firmware' as a new content type.

> This does not change anything for efidisk0.

What exactly do you mean here? That the schema/behavior for efidisk0
still is the same? I suppose you'll also warn if an EFI disk is attached
to a confidential VM like currently happens?

> Storage handling for firmware files and VM configuration shall be
> accessible from the API as a first step. We are not very concerned
> about the web interface. Does that approach make sense to you? Is it ok
> to go with a new content type or are there better alternatives?
> 
> 
>   - Christian
> 
> [1] https://bugzilla.proxmox.com/show_bug.cgi?id=5898
> [2] https://bugzilla.proxmox.com/show_bug.cgi?id=7258

[0]:
https://lore.proxmox.com/pve-devel/20250729111557.136012-1-w.bumiller@proxmox.com/

Best Regards,
Fiona