Re: Design for custom UEFI firmware in PVE

[Christian Ludwig <christian_ludwig@genua.de>]

[-- Attachment #1: Type: text/plain, Size: 4653 bytes --]

Hi,

On Thu, 2026-04-23 at 18:24 +0200, Fiona Ebner wrote:
> 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.

Thanks for raising this. We will keep it in mind.

> 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'.

EFI firmware files behave like case 3, its a 1:n mapping. Custom EFI
firmware files are read-only. They contain the code section only. EFI-
data is handled via efidisk0, if needed.

> 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.

Agreed.

> > 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?

Yes, we do not plan to change any behavior related to efidisk0. Custom
EFI firmware files contain the code section only and confidential VMs
only have an EFI firmware with code. Normal VMs that bring their own
firmware, like in the SonicWall case, also need an efidisk0 attached
for data. Our goal is to make that work. But none of that treats
efidisk0 any different from the current situation.

Hope that makes things a bit more clear.

> > 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