Design for custom UEFI firmware in PVE

Design for custom UEFI firmware in PVE

[Christian Ludwig]

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

Hi,

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.

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.
This does not change anything for efidisk0.

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

Re: Design for custom UEFI firmware in PVE

[Fiona Ebner]

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