Re: Design for custom UEFI firmware in PVE

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

Am 28.04.26 um 2:12 PM schrieb Christian Ludwig:
> 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.

Okay, I see. So there can be a new 'efi-firmware' content/volume type
with upload support in the storage layer and the possibility to set such
volumes in the relevant (yet-to-be-introduced) config option of a VM.

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

Yes, thank you for the clarification!

I don't see any initial blockers with this design :)

Best Regards,
Fiona

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