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

Re: Design for custom UEFI firmware in PVE

[Christian Ludwig]

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