public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Christian Ludwig <christian_ludwig@genua.de>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Subject: Design for custom UEFI firmware in PVE
Date: Fri, 17 Apr 2026 16:33:10 +0000	[thread overview]
Message-ID: <10513e3f2c0d94bc938a540b4a0a18749eb5ed96.camel@genua.de> (raw)

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

                 reply	other threads:[~2026-04-17 16:39 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=10513e3f2c0d94bc938a540b4a0a18749eb5ed96.camel@genua.de \
    --to=christian_ludwig@genua.de \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal