From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id EC4661FF187 for ; Tue, 18 Nov 2025 13:58:57 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E3566144CF; Tue, 18 Nov 2025 13:58:59 +0100 (CET) Date: Tue, 18 Nov 2025 13:58:52 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox VE development discussion References: <20251118123516.112546-1-f.ebner@proxmox.com> <20251118123516.112546-3-f.ebner@proxmox.com> In-Reply-To: <20251118123516.112546-3-f.ebner@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.17.0 (https://github.com/astroidmail/astroid) Message-Id: <1763470464.ao41v90w30.astroid@yuna.none> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1763470706108 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.045 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [qemu.pm, proxmox.com, qm.pm] Subject: Re: [pve-devel] [PATCH qemu-server 2/4] api/cli: add enroll-efi-keys endpoint X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On November 18, 2025 1:34 pm, Fiona Ebner wrote: > A new enroll-efi-keys API endpoint and command for qm is added. It > enrolls the latest known-to-be-important certificates to the EFI disk, > which currently is just the Microsoft UEFI CA 2023. > > Signed-off-by: Fiona Ebner > --- > src/PVE/API2/Qemu.pm | 60 ++++++++++++++++++++++++++++++++++++++++++++ > src/PVE/CLI/qm.pm | 2 ++ > 2 files changed, 62 insertions(+) > > diff --git a/src/PVE/API2/Qemu.pm b/src/PVE/API2/Qemu.pm > index 5cdba4bb..665afbe2 100644 > --- a/src/PVE/API2/Qemu.pm > +++ b/src/PVE/API2/Qemu.pm > @@ -7048,4 +7048,64 @@ __PACKAGE__->register_method({ > }, > }); > > +__PACKAGE__->register_method({ > + name => 'enroll-efi-keys', > + path => '{vmid}/enroll-efi-keys', > + method => 'POST', > + protected => 1, > + proxyto => 'node', > + description => > + "Enroll important updated certificates to the EFI disk with pre-enrolled-keys. Currently," > + . " this is only the Microsoft UEFI CA 2023. Must be called while the VM is shut down.", > + permissions => { > + check => ['perm', '/vms/{vmid}', ['VM.Config.Disk']], > + }, > + parameters => { > + additionalProperties => 0, > + properties => { > + node => get_standard_option('pve-node'), > + vmid => > + get_standard_option('pve-vmid', { completion => \&PVE::QemuServer::complete_vmid }), > + }, > + }, > + returns => { type => 'null' }, > + code => sub { > + my ($param) = @_; > + > + my $vmid = extract_param($param, 'vmid'); > + > + my $enroll_fn = sub { > + my $conf = PVE::QemuConfig->load_config($vmid); > + > + PVE::QemuConfig->check_lock($conf); > + die "VM $vmid is running\n" if PVE::QemuServer::Helpers::vm_running_locally($vmid); > + die "VM $vmid is a template\n" if PVE::QemuConfig->is_template($conf); > + die "VM $vmid has no EFI disk configured\n" if !$conf->{efidisk0}; > + > + my $ostype = $conf->{ostype}; > + if (!defined($ostype) || ($ostype ne 'win10' && $ostype ne 'win11')) { > + print "skipping - OS type is neither Windows 10 nor Windows 11\n"; > + return; > + } > + > + my $storecfg = PVE::Storage::config(); > + > + my $updated = PVE::QemuServer::OVMF::ensure_ms_2023_cert_enrolled( > + $storecfg, $vmid, $conf->{efidisk0}, > + ); this can block and/or take a while, so shouldn't this endpoint fork a task worker? and do we really need a new endpoint for this, couldn't we do it in the config update and let the UI set the corresponding EFI disk flag as an (async) update? > + if ($updated) { > + $conf->{efidisk0} = $updated; > + PVE::QemuConfig->write_config($vmid, $conf); > + } else { > + print "skipping - no pre-enrolled keys or already got ms-cert=2023 marker\n"; > + } > + > + return; > + }; > + > + PVE::QemuConfig->lock_config($vmid, $enroll_fn); > + return; > + }, > +}); > + > 1; > diff --git a/src/PVE/CLI/qm.pm b/src/PVE/CLI/qm.pm > index 9398780e..d0f80b20 100755 > --- a/src/PVE/CLI/qm.pm > +++ b/src/PVE/CLI/qm.pm > @@ -1341,6 +1341,8 @@ our $cmddef = { > unlink => ["PVE::API2::Qemu", 'unlink', ['vmid'], {%node}], > }, > > + 'enroll-efi-keys' => ["PVE::API2::Qemu", 'enroll-efi-keys', ['vmid'], {%node}], > + > monitor => [__PACKAGE__, 'monitor', ['vmid']], > > agent => { alias => 'guest cmd' }, # FIXME: remove with PVE 8.0 > -- > 2.47.3 > > > > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > > > _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel