all lists on 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal