public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
* [pve-devel] [PATCH-SERIES qemu-server 0/2] fix #6985: ovmf: auto-enroll Microsoft UEFI CA 2023 for Windows
@ 2025-11-11 13:57 Fiona Ebner
  2025-11-11 13:57 ` [pve-devel] [PATCH qemu-server 1/2] qsd: add remove_fuse_export() function Fiona Ebner
  2025-11-11 13:57 ` [pve-devel] [PATCH qemu-server 2/2] fix #6985: ovmf: auto-enroll Microsoft UEFI CA 2023 for Windows Fiona Ebner
  0 siblings, 2 replies; 9+ messages in thread
From: Fiona Ebner @ 2025-11-11 13:57 UTC (permalink / raw)
  To: pve-devel

This is a followup to [0], taking care of already existing EFI disks.

See the bug report [1] and patch 2/2 for details.

Depends on the QSD parts of [2].

[0]: https://lore.proxmox.com/pve-devel/20251106154314.772317-1-f.ebner@proxmox.com/
[1]: https://bugzilla.proxmox.com/show_bug.cgi?id=6985
[2]: https://lore.proxmox.com/pve-devel/20251020141335.124077-1-f.ebner@proxmox.com/

Fiona Ebner (2):
  qsd: add remove_fuse_export() function
  fix #6985: ovmf: auto-enroll Microsoft UEFI CA 2023 for Windows

 debian/control              |  1 +
 src/PVE/QemuServer.pm       | 20 +++++++++++++
 src/PVE/QemuServer/Drive.pm |  9 ++++++
 src/PVE/QemuServer/OVMF.pm  | 59 +++++++++++++++++++++++++++++++++++++
 src/PVE/QemuServer/QSD.pm   | 14 +++++++++
 5 files changed, 103 insertions(+)

-- 
2.47.3



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [pve-devel] [PATCH qemu-server 1/2] qsd: add remove_fuse_export() function
  2025-11-11 13:57 [pve-devel] [PATCH-SERIES qemu-server 0/2] fix #6985: ovmf: auto-enroll Microsoft UEFI CA 2023 for Windows Fiona Ebner
@ 2025-11-11 13:57 ` Fiona Ebner
  2025-11-14 11:50   ` [pve-devel] applied: " Thomas Lamprecht
  2025-11-11 13:57 ` [pve-devel] [PATCH qemu-server 2/2] fix #6985: ovmf: auto-enroll Microsoft UEFI CA 2023 for Windows Fiona Ebner
  1 sibling, 1 reply; 9+ messages in thread
From: Fiona Ebner @ 2025-11-11 13:57 UTC (permalink / raw)
  To: pve-devel

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---
 src/PVE/QemuServer/QSD.pm | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/src/PVE/QemuServer/QSD.pm b/src/PVE/QemuServer/QSD.pm
index 897ed9cd..9c30f7fd 100644
--- a/src/PVE/QemuServer/QSD.pm
+++ b/src/PVE/QemuServer/QSD.pm
@@ -85,6 +85,20 @@ sub add_fuse_export($id, $drive, $name) {
     return $fuse_path;
 }
 
+=head3 remove_fuse_export
+
+    PVE::QemuServer::QSD::remove_fuse_export($id, $name);
+
+Remove the export with name C<$name> from the storage daemon with ID C<$id>.
+
+=cut
+
+sub remove_fuse_export($id, $name) {
+    PVE::QemuServer::Monitor::qsd_cmd($id, 'block-export-del', id => "$name");
+
+    return;
+}
+
 =head3 quit
 
     PVE::QemuServer::QSD::quit($id);
-- 
2.47.3



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [pve-devel] [PATCH qemu-server 2/2] fix #6985: ovmf: auto-enroll Microsoft UEFI CA 2023 for Windows
  2025-11-11 13:57 [pve-devel] [PATCH-SERIES qemu-server 0/2] fix #6985: ovmf: auto-enroll Microsoft UEFI CA 2023 for Windows Fiona Ebner
  2025-11-11 13:57 ` [pve-devel] [PATCH qemu-server 1/2] qsd: add remove_fuse_export() function Fiona Ebner
@ 2025-11-11 13:57 ` Fiona Ebner
  2025-11-14  1:18   ` Thomas Lamprecht
  1 sibling, 1 reply; 9+ messages in thread
From: Fiona Ebner @ 2025-11-11 13:57 UTC (permalink / raw)
  To: pve-devel

Microsoft's UEFI CA 2011 will expire in June 2026. It's necessary to
ensure that the new UEFI CA 2023 is enrolled for Windows to keep
updates working.

pve-edk2-firmware >= 4.2025.05-1 includes the 2023 certificate
already, so new disks are fine. Still, check during EFI disk creation
what is actually there, since there is no guarantee that a new enough
version of pve-edk2-firmware is installed.

A new 'ms-cert' drive property for EFI disks records the year of the
last known-to-be-enrolled MS UEFI CA. This avoids the need to re-check
every time if the 2023 certificate needs to be enrolled. The downside
is that this breaks backwards migration, because a disk with an
unknown option is dropped from the configuration.

Enrollment and checking for existing disks is done via virt-fw-vars,
which is a new dependency recorded in d/control. While virt-fw-vars
supports raw and qcow2 files out of the box, this is not enough,
because EFI disks can also be vmdk formatted and there are also
storages that use a protocol path like 'rbd://' or 'iscsi://' for
QEMU, which virt-fw-vars cannot handle. Thus, use a FUSE export to
cover all cases.

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---
 debian/control              |  1 +
 src/PVE/QemuServer.pm       | 20 +++++++++++++
 src/PVE/QemuServer/Drive.pm |  9 ++++++
 src/PVE/QemuServer/OVMF.pm  | 59 +++++++++++++++++++++++++++++++++++++
 4 files changed, 89 insertions(+)

diff --git a/debian/control b/debian/control
index 5ac6b0fc..661ac65b 100644
--- a/debian/control
+++ b/debian/control
@@ -58,6 +58,7 @@ Depends: conntrack,
          pve-firewall (>= 6.0.3),
          pve-ha-manager (>= 5.0.3),
          pve-qemu-kvm (>= 7.1~),
+         python3-virt-firmware,
          socat,
          swtpm,
          swtpm-tools,
diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm
index 79ff637a..74836833 100644
--- a/src/PVE/QemuServer.pm
+++ b/src/PVE/QemuServer.pm
@@ -5373,6 +5373,24 @@ my sub remove_left_over_vmstate_opts {
     PVE::QemuConfig->write_config($vmid, $conf) if $found;
 }
 
+my sub check_efi_vars {
+    my ($storecfg, $vmid, $conf) = @_;
+
+    return if PVE::QemuConfig->is_template($conf);
+    return if !$conf->{efidisk0};
+    return if $conf->{ostype} ne 'win10' && $conf->{ostype} ne 'win11';
+
+    if (
+        my $updated = PVE::QemuServer::OVMF::ensure_ms_2023_cert_enrolled(
+            $storecfg, $vmid, $conf->{efidisk0},
+        )
+    ) {
+        $conf->{efidisk0} = $updated;
+        PVE::QemuConfig->write_config($vmid, $conf);
+    }
+    return;
+}
+
 # see vm_start_nolock for parameters, additionally:
 # migrate_opts:
 #   storagemap = parsed storage map for allocating NBD disks
@@ -5548,6 +5566,8 @@ sub vm_start_nolock {
         # With -blockdev, it is necessary to activate the volumes before generating the command line
         PVE::Storage::activate_volumes($storecfg, $vollist);
 
+        check_efi_vars($storecfg, $vmid, $conf) if $conf->{bios} && $conf->{bios} eq 'ovmf';
+
         # Note that for certain cases like templates, the configuration is minimized, so need to ensure
         # the rest of the function here uses the same configuration that was used to build the command
         ($cmd, $spice_port, my $pci_devices, $conf) = config_to_command(
diff --git a/src/PVE/QemuServer/Drive.pm b/src/PVE/QemuServer/Drive.pm
index f54f9612..c772c803 100644
--- a/src/PVE/QemuServer/Drive.pm
+++ b/src/PVE/QemuServer/Drive.pm
@@ -521,6 +521,15 @@ my %efitype_fmt = (
         optional => 1,
         default => 0,
     },
+    'ms-cert' => {
+        type => 'string',
+        enum => [qw(2011 2023)],
+        description =>
+            "Informational marker indicating the version of the latest Microsof UEFI certificate"
+            . " that has been enrolled by Proxmox VE.",
+        optional => 1,
+        default => '2011',
+    },
 );
 
 my $efidisk_fmt = {
diff --git a/src/PVE/QemuServer/OVMF.pm b/src/PVE/QemuServer/OVMF.pm
index 08134e30..badacf54 100644
--- a/src/PVE/QemuServer/OVMF.pm
+++ b/src/PVE/QemuServer/OVMF.pm
@@ -11,7 +11,9 @@ use PVE::Tools;
 
 use PVE::QemuServer::Blockdev;
 use PVE::QemuServer::Drive qw(checked_volume_format parse_drive print_drive);
+use PVE::QemuServer::Helpers;
 use PVE::QemuServer::QemuImage;
+use PVE::QemuServer::QSD;
 
 my $EDK2_FW_BASE = '/usr/share/pve-edk2-firmware/';
 my $OVMF = {
@@ -128,6 +130,30 @@ sub get_efivars_size {
     return -s $ovmf_vars;
 }
 
+my sub is_ms_2023_cert_enrolled {
+    my ($path) = @_;
+
+    my $inside_db_section;
+    my $found_ms_2023_cert;
+
+    my $detect_ms_2023_cert = sub {
+        my ($line) = @_;
+        return if $found_ms_2023_cert;
+        $inside_db_section = undef if !$line;
+        $found_ms_2023_cert = 1
+            if $inside_db_section && $line =~ m/CN=Microsoft UEFI CA 2023/;
+        $inside_db_section = 1 if $line =~ m/^name=db guid=guid:EfiImageSecurityDatabase/;
+        return;
+    };
+
+    PVE::Tools::run_command(
+        ['virt-fw-vars', '--input', $path, '--print', '--verbose'],
+        outfunc => $detect_ms_2023_cert,
+    );
+
+    return $found_ms_2023_cert;
+}
+
 sub create_efidisk($$$$$$$$) {
     my ($storecfg, $storeid, $vmid, $fmt, $arch, $efidisk, $smm, $amd_sev_type) = @_;
 
@@ -141,6 +167,10 @@ sub create_efidisk($$$$$$$$) {
     PVE::QemuServer::QemuImage::convert($ovmf_vars, $volid, $vars_size_b);
     my $size = PVE::Storage::volume_size_info($storecfg, $volid, 3);
 
+    if ($efidisk->{'pre-enrolled-keys'} && is_ms_2023_cert_enrolled($ovmf_vars)) {
+        $efidisk->{'ms-cert'} = '2023'
+    }
+
     return ($volid, $size / 1024);
 }
 
@@ -235,4 +265,33 @@ sub print_ovmf_commandline {
     return ($cmd, $machine_flags);
 }
 
+sub ensure_ms_2023_cert_enrolled {
+    my ($storecfg, $vmid, $efidisk_str) = @_;
+
+    my $efidisk = parse_drive('efidisk0', $efidisk_str);
+    return if !$efidisk->{'pre-enrolled-keys'};
+    return if $efidisk->{'ms-cert'} && $efidisk->{'ms-cert'} eq '2023';
+
+    print "efidisk0: enrolling Microsoft UEFI CA 2023\n";
+
+    my $new_qsd = !PVE::QemuServer::Helpers::qsd_running_locally($vmid);
+    PVE::QemuServer::QSD::start($vmid) if $new_qsd;
+
+    eval {
+        my $efi_vars_path =
+            PVE::QemuServer::QSD::add_fuse_export($vmid, $efidisk, 'efidisk0-enroll');
+        PVE::Tools::run_command(
+            ['virt-fw-vars', '--inplace', $efi_vars_path, '--distro-keys', 'ms-uefi']);
+        PVE::QemuServer::QSD::remove_fuse_export($vmid, 'efidisk0-enroll');
+    };
+    my $err = $@;
+
+    PVE::QemuServer::QSD::quit($vmid) if $new_qsd;
+
+    die "efidisk0: enrolling Microsoft UEFI CA 2023 failed - $err" if $err;
+
+    $efidisk->{'ms-cert'} = '2023';
+    return print_drive($efidisk);
+}
+
 1;
-- 
2.47.3



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [pve-devel] [PATCH qemu-server 2/2] fix #6985: ovmf: auto-enroll Microsoft UEFI CA 2023 for Windows
  2025-11-11 13:57 ` [pve-devel] [PATCH qemu-server 2/2] fix #6985: ovmf: auto-enroll Microsoft UEFI CA 2023 for Windows Fiona Ebner
@ 2025-11-14  1:18   ` Thomas Lamprecht
  2025-11-14 11:03     ` Fiona Ebner
  0 siblings, 1 reply; 9+ messages in thread
From: Thomas Lamprecht @ 2025-11-14  1:18 UTC (permalink / raw)
  To: Proxmox VE development discussion, Fiona Ebner

Am 11.11.25 um 14:57 schrieb Fiona Ebner:
> Microsoft's UEFI CA 2011 will expire in June 2026. It's necessary to
> ensure that the new UEFI CA 2023 is enrolled for Windows to keep
> updates working.
> 
> pve-edk2-firmware >= 4.2025.05-1 includes the 2023 certificate
> already, so new disks are fine. Still, check during EFI disk creation
> what is actually there, since there is no guarantee that a new enough
> version of pve-edk2-firmware is installed.
> 
> A new 'ms-cert' drive property for EFI disks records the year of the
> last known-to-be-enrolled MS UEFI CA. This avoids the need to re-check
> every time if the 2023 certificate needs to be enrolled. The downside
> is that this breaks backwards migration, because a disk with an
> unknown option is dropped from the configuration.
> 
> Enrollment and checking for existing disks is done via virt-fw-vars,
> which is a new dependency recorded in d/control. While virt-fw-vars
> supports raw and qcow2 files out of the box, this is not enough,
> because EFI disks can also be vmdk formatted and there are also
> storages that use a protocol path like 'rbd://' or 'iscsi://' for
> QEMU, which virt-fw-vars cannot handle. Thus, use a FUSE export to
> cover all cases.
> 
> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
> ---
>  debian/control              |  1 +
>  src/PVE/QemuServer.pm       | 20 +++++++++++++
>  src/PVE/QemuServer/Drive.pm |  9 ++++++
>  src/PVE/QemuServer/OVMF.pm  | 59 +++++++++++++++++++++++++++++++++++++
>  4 files changed, 89 insertions(+)
> 
needs a rebase (or I fumbled something).

> diff --git a/debian/control b/debian/control
> index 5ac6b0fc..661ac65b 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -58,6 +58,7 @@ Depends: conntrack,
>           pve-firewall (>= 6.0.3),
>           pve-ha-manager (>= 5.0.3),
>           pve-qemu-kvm (>= 7.1~),
> +         python3-virt-firmware,
>           socat,
>           swtpm,
>           swtpm-tools,
> diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm
> index 79ff637a..74836833 100644
> --- a/src/PVE/QemuServer.pm
> +++ b/src/PVE/QemuServer.pm
> @@ -5373,6 +5373,24 @@ my sub remove_left_over_vmstate_opts {
>      PVE::QemuConfig->write_config($vmid, $conf) if $found;
>  }
>  
> +my sub check_efi_vars {
> +    my ($storecfg, $vmid, $conf) = @_;
> +
> +    return if PVE::QemuConfig->is_template($conf);
> +    return if !$conf->{efidisk0};
> +    return if $conf->{ostype} ne 'win10' && $conf->{ostype} ne 'win11';
> +
> +    if (
> +        my $updated = PVE::QemuServer::OVMF::ensure_ms_2023_cert_enrolled(
> +            $storecfg, $vmid, $conf->{efidisk0},
> +        )
> +    ) {
> +        $conf->{efidisk0} = $updated;
> +        PVE::QemuConfig->write_config($vmid, $conf);
> +    }
> +    return;
> +}
> +
>  # see vm_start_nolock for parameters, additionally:
>  # migrate_opts:
>  #   storagemap = parsed storage map for allocating NBD disks
> @@ -5548,6 +5566,8 @@ sub vm_start_nolock {
>          # With -blockdev, it is necessary to activate the volumes before generating the command line
>          PVE::Storage::activate_volumes($storecfg, $vollist);
>  
> +        check_efi_vars($storecfg, $vmid, $conf) if $conf->{bios} && $conf->{bios} eq 'ovmf';
> +
>          # Note that for certain cases like templates, the configuration is minimized, so need to ensure
>          # the rest of the function here uses the same configuration that was used to build the command
>          ($cmd, $spice_port, my $pci_devices, $conf) = config_to_command(
> diff --git a/src/PVE/QemuServer/Drive.pm b/src/PVE/QemuServer/Drive.pm
> index f54f9612..c772c803 100644
> --- a/src/PVE/QemuServer/Drive.pm
> +++ b/src/PVE/QemuServer/Drive.pm
> @@ -521,6 +521,15 @@ my %efitype_fmt = (
>          optional => 1,
>          default => 0,
>      },
> +    'ms-cert' => {
> +        type => 'string',
> +        enum => [qw(2011 2023)],
> +        description =>
> +            "Informational marker indicating the version of the latest Microsof UEFI certificate"
> +            . " that has been enrolled by Proxmox VE.",
> +        optional => 1,
> +        default => '2011',
> +    },
>  );
>  
>  my $efidisk_fmt = {
> diff --git a/src/PVE/QemuServer/OVMF.pm b/src/PVE/QemuServer/OVMF.pm
> index 08134e30..badacf54 100644
> --- a/src/PVE/QemuServer/OVMF.pm
> +++ b/src/PVE/QemuServer/OVMF.pm
> @@ -11,7 +11,9 @@ use PVE::Tools;
>  
>  use PVE::QemuServer::Blockdev;
>  use PVE::QemuServer::Drive qw(checked_volume_format parse_drive print_drive);
> +use PVE::QemuServer::Helpers;
>  use PVE::QemuServer::QemuImage;
> +use PVE::QemuServer::QSD;
>  
>  my $EDK2_FW_BASE = '/usr/share/pve-edk2-firmware/';
>  my $OVMF = {
> @@ -128,6 +130,30 @@ sub get_efivars_size {
>      return -s $ovmf_vars;
>  }
>  
> +my sub is_ms_2023_cert_enrolled {
> +    my ($path) = @_;
> +
> +    my $inside_db_section;
> +    my $found_ms_2023_cert;
> +
> +    my $detect_ms_2023_cert = sub {
> +        my ($line) = @_;
> +        return if $found_ms_2023_cert;
> +        $inside_db_section = undef if !$line;
> +        $found_ms_2023_cert = 1
> +            if $inside_db_section && $line =~ m/CN=Microsoft UEFI CA 2023/;
> +        $inside_db_section = 1 if $line =~ m/^name=db guid=guid:EfiImageSecurityDatabase/;
> +        return;
> +    };
> +
> +    PVE::Tools::run_command(
> +        ['virt-fw-vars', '--input', $path, '--print', '--verbose'],
> +        outfunc => $detect_ms_2023_cert,
> +    );
> +
> +    return $found_ms_2023_cert;
> +}
> +
>  sub create_efidisk($$$$$$$$) {
>      my ($storecfg, $storeid, $vmid, $fmt, $arch, $efidisk, $smm, $amd_sev_type) = @_;
>  
> @@ -141,6 +167,10 @@ sub create_efidisk($$$$$$$$) {
>      PVE::QemuServer::QemuImage::convert($ovmf_vars, $volid, $vars_size_b);
>      my $size = PVE::Storage::volume_size_info($storecfg, $volid, 3);
>  
> +    if ($efidisk->{'pre-enrolled-keys'} && is_ms_2023_cert_enrolled($ovmf_vars)) {
> +        $efidisk->{'ms-cert'} = '2023'
> +    }
> +
>      return ($volid, $size / 1024);
>  }
>  
> @@ -235,4 +265,33 @@ sub print_ovmf_commandline {
>      return ($cmd, $machine_flags);
>  }
>  
> +sub ensure_ms_2023_cert_enrolled {
> +    my ($storecfg, $vmid, $efidisk_str) = @_;
> +
> +    my $efidisk = parse_drive('efidisk0', $efidisk_str);
> +    return if !$efidisk->{'pre-enrolled-keys'};
> +    return if $efidisk->{'ms-cert'} && $efidisk->{'ms-cert'} eq '2023';
> +
> +    print "efidisk0: enrolling Microsoft UEFI CA 2023\n";
> +
> +    my $new_qsd = !PVE::QemuServer::Helpers::qsd_running_locally($vmid);
> +    PVE::QemuServer::QSD::start($vmid) if $new_qsd;
> +
> +    eval {
> +        my $efi_vars_path =
> +            PVE::QemuServer::QSD::add_fuse_export($vmid, $efidisk, 'efidisk0-enroll');
> +        PVE::Tools::run_command(
> +            ['virt-fw-vars', '--inplace', $efi_vars_path, '--distro-keys', 'ms-uefi']);
> +        PVE::QemuServer::QSD::remove_fuse_export($vmid, 'efidisk0-enroll');
> +    };
> +    my $err = $@;
> +
> +    PVE::QemuServer::QSD::quit($vmid) if $new_qsd;

if other request start using this QSD after it was started here they might get
interrupted? Albeit currently this is probably rather theoretically due to QSD
being per-vmid and we the operations QSD is used as of now are not really being
able to run concurently for a single VM FWICT.

Might be still good to at least add a comment for this for the case that QSD gets
adopted more.

> +
> +    die "efidisk0: enrolling Microsoft UEFI CA 2023 failed - $err" if $err;
> +
> +    $efidisk->{'ms-cert'} = '2023';
> +    return print_drive($efidisk);
> +}
> +
>  1;



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [pve-devel] [PATCH qemu-server 2/2] fix #6985: ovmf: auto-enroll Microsoft UEFI CA 2023 for Windows
  2025-11-14  1:18   ` Thomas Lamprecht
@ 2025-11-14 11:03     ` Fiona Ebner
  2025-11-14 11:48       ` Thomas Lamprecht
  0 siblings, 1 reply; 9+ messages in thread
From: Fiona Ebner @ 2025-11-14 11:03 UTC (permalink / raw)
  To: Thomas Lamprecht, Proxmox VE development discussion

Am 14.11.25 um 2:18 AM schrieb Thomas Lamprecht:
> Am 11.11.25 um 14:57 schrieb Fiona Ebner:
> needs a rebase (or I fumbled something).

Probably because of the sev->cvm rename as part of the TDX series. Will do!

>> @@ -235,4 +265,33 @@ sub print_ovmf_commandline {
>>      return ($cmd, $machine_flags);
>>  }
>>  
>> +sub ensure_ms_2023_cert_enrolled {
>> +    my ($storecfg, $vmid, $efidisk_str) = @_;
>> +
>> +    my $efidisk = parse_drive('efidisk0', $efidisk_str);
>> +    return if !$efidisk->{'pre-enrolled-keys'};
>> +    return if $efidisk->{'ms-cert'} && $efidisk->{'ms-cert'} eq '2023';
>> +
>> +    print "efidisk0: enrolling Microsoft UEFI CA 2023\n";
>> +
>> +    my $new_qsd = !PVE::QemuServer::Helpers::qsd_running_locally($vmid);
>> +    PVE::QemuServer::QSD::start($vmid) if $new_qsd;
>> +
>> +    eval {
>> +        my $efi_vars_path =
>> +            PVE::QemuServer::QSD::add_fuse_export($vmid, $efidisk, 'efidisk0-enroll');
>> +        PVE::Tools::run_command(
>> +            ['virt-fw-vars', '--inplace', $efi_vars_path, '--distro-keys', 'ms-uefi']);
>> +        PVE::QemuServer::QSD::remove_fuse_export($vmid, 'efidisk0-enroll');
>> +    };
>> +    my $err = $@;
>> +
>> +    PVE::QemuServer::QSD::quit($vmid) if $new_qsd;
> 
> if other request start using this QSD after it was started here they might get
> interrupted? Albeit currently this is probably rather theoretically due to QSD
> being per-vmid and we the operations QSD is used as of now are not really being
> able to run concurently for a single VM FWICT.
> 
> Might be still good to at least add a comment for this for the case that QSD gets
> adopted more.

Yes, we will need to be careful down the line. A clean option is using
different QSD IDs for different tasks (the ID for a QSD can be any
string and does not need to be a VMID). Currently, we only use QSD for
EFI enrollment here and for TPM which are both part of the same start
task. I will add a comment to note this and that
ensure_ms_2023_cert_enrolled() may currently only be called as part of
VM start.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [pve-devel] [PATCH qemu-server 2/2] fix #6985: ovmf: auto-enroll Microsoft UEFI CA 2023 for Windows
  2025-11-14 11:03     ` Fiona Ebner
@ 2025-11-14 11:48       ` Thomas Lamprecht
  2025-11-14 12:03         ` Fiona Ebner
  0 siblings, 1 reply; 9+ messages in thread
From: Thomas Lamprecht @ 2025-11-14 11:48 UTC (permalink / raw)
  To: Fiona Ebner, Proxmox VE development discussion

Am 14.11.25 um 12:03 schrieb Fiona Ebner:
> Yes, we will need to be careful down the line. A clean option is using
> different QSD IDs for different tasks (the ID for a QSD can be any
> string and does not need to be a VMID). Currently, we only use QSD for
> EFI enrollment here and for TPM which are both part of the same start
> task. I will add a comment to note this and that
> ensure_ms_2023_cert_enrolled() may currently only be called as part of
> VM start.


Oh, and what I just noticed: the QSD is currently not running inside of
the qemu.slice/$vmid.scope?

Not a blocker at all now, but that might be nice to have to ensure it's
resource (mainly memory) usage is accounted for.





_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [pve-devel] applied: [PATCH qemu-server 1/2] qsd: add remove_fuse_export() function
  2025-11-11 13:57 ` [pve-devel] [PATCH qemu-server 1/2] qsd: add remove_fuse_export() function Fiona Ebner
@ 2025-11-14 11:50   ` Thomas Lamprecht
  0 siblings, 0 replies; 9+ messages in thread
From: Thomas Lamprecht @ 2025-11-14 11:50 UTC (permalink / raw)
  To: Proxmox VE development discussion, Fiona Ebner

Am 11.11.25 um 14:57 schrieb Fiona Ebner:
> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
> ---
>  src/PVE/QemuServer/QSD.pm | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
>

applied this one already, thanks!


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [pve-devel] [PATCH qemu-server 2/2] fix #6985: ovmf: auto-enroll Microsoft UEFI CA 2023 for Windows
  2025-11-14 11:48       ` Thomas Lamprecht
@ 2025-11-14 12:03         ` Fiona Ebner
  2025-11-14 12:12           ` Thomas Lamprecht
  0 siblings, 1 reply; 9+ messages in thread
From: Fiona Ebner @ 2025-11-14 12:03 UTC (permalink / raw)
  To: Thomas Lamprecht, Proxmox VE development discussion

Am 14.11.25 um 12:47 PM schrieb Thomas Lamprecht:
> Am 14.11.25 um 12:03 schrieb Fiona Ebner:
>> Yes, we will need to be careful down the line. A clean option is using
>> different QSD IDs for different tasks (the ID for a QSD can be any
>> string and does not need to be a VMID). Currently, we only use QSD for
>> EFI enrollment here and for TPM which are both part of the same start
>> task. I will add a comment to note this and that
>> ensure_ms_2023_cert_enrolled() may currently only be called as part of
>> VM start.
> 
> 
> Oh, and what I just noticed: the QSD is currently not running inside of
> the qemu.slice/$vmid.scope?
> 
> Not a blocker at all now, but that might be nice to have to ensure it's
> resource (mainly memory) usage is accounted for.

The one started for enrollment is not, but that one is very short-lived.
The one for started for swtpm should actually be? It's part of the
start_swtpm() function.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [pve-devel] [PATCH qemu-server 2/2] fix #6985: ovmf: auto-enroll Microsoft UEFI CA 2023 for Windows
  2025-11-14 12:03         ` Fiona Ebner
@ 2025-11-14 12:12           ` Thomas Lamprecht
  0 siblings, 0 replies; 9+ messages in thread
From: Thomas Lamprecht @ 2025-11-14 12:12 UTC (permalink / raw)
  To: Fiona Ebner, Proxmox VE development discussion

Am 14.11.25 um 13:03 schrieb Fiona Ebner:
> Am 14.11.25 um 12:47 PM schrieb Thomas Lamprecht:
>> Am 14.11.25 um 12:03 schrieb Fiona Ebner:
>>> Yes, we will need to be careful down the line. A clean option is using
>>> different QSD IDs for different tasks (the ID for a QSD can be any
>>> string and does not need to be a VMID). Currently, we only use QSD for
>>> EFI enrollment here and for TPM which are both part of the same start
>>> task. I will add a comment to note this and that
>>> ensure_ms_2023_cert_enrolled() may currently only be called as part of
>>> VM start.
>>
>>
>> Oh, and what I just noticed: the QSD is currently not running inside of
>> the qemu.slice/$vmid.scope?
>>
>> Not a blocker at all now, but that might be nice to have to ensure it's
>> resource (mainly memory) usage is accounted for.
> 
> The one started for enrollment is not, but that one is very short-lived.
> The one for started for swtpm should actually be? It's part of the
> start_swtpm() function.

True, and as you say that's the more important one anyway due to running
for the entire time such a VM is running.
So fine as is for now, we can change this at anytime anyway.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2025-11-14 12:12 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-11-11 13:57 [pve-devel] [PATCH-SERIES qemu-server 0/2] fix #6985: ovmf: auto-enroll Microsoft UEFI CA 2023 for Windows Fiona Ebner
2025-11-11 13:57 ` [pve-devel] [PATCH qemu-server 1/2] qsd: add remove_fuse_export() function Fiona Ebner
2025-11-14 11:50   ` [pve-devel] applied: " Thomas Lamprecht
2025-11-11 13:57 ` [pve-devel] [PATCH qemu-server 2/2] fix #6985: ovmf: auto-enroll Microsoft UEFI CA 2023 for Windows Fiona Ebner
2025-11-14  1:18   ` Thomas Lamprecht
2025-11-14 11:03     ` Fiona Ebner
2025-11-14 11:48       ` Thomas Lamprecht
2025-11-14 12:03         ` Fiona Ebner
2025-11-14 12:12           ` Thomas Lamprecht

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