- Devel - libvirt List Archives

[RFC 0/4] cover: RFE libvirt secret encryption on disk
by Arun Menon 17 Nov '25

17 Nov '25

Libvirt secrets are stored unencrypted on the disk. With this series we want to start encrypting the secrets. First we introduce a secrets.conf file that has 2 configuration settings. 1. encrypt_data - This can be set to 0 or 1. If it is set to 1 then we encrypt the secrets. We recommend to keep this as the default setting. 2. master_encryption_key - This allows the user to set the path of the encryption file. The secrets.conf file is parsed during secrets driver initialization and accordingly the secrets are stored on the disk. By default the secrets driver will look into the CREDENTIALS_DIRECTORY environment variable in systemd. The systemd unit file is configured with a pre configured key using the SetCredentialEncrypted directive. This encrypted secret key is provided to the virtsecretd on service activation. If this file is not available, then the virtsecretd driver will check the master_encryption_key configuration in secrets.conf file, provided it is made available by the user. A boolean flag called value_encrypted is added to the secrets object, to indicate whether it is encrypted or not. This is not stored on the disk yet. It is important to add this functionality so that the secrets service behaves properly across restarts. This is a sincere attempt to improve upon the already submitted patch https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/KE6G… Resolves: https://issues.redhat.com/browse/RHEL-7125 Arun Menon (4): util: Add support for GnuTLS decryption secret: Set up default encrypted master key for the virtsecretd service secret: Add secrets.conf configuration file and parse it secret: Add functionality to load and save secrets in encrypted format libvirt.spec.in | 1 + src/conf/virsecretobj.c | 13 ++ src/conf/virsecretobj.h | 7 + src/libvirt_private.syms | 3 + src/secret/meson.build | 7 + src/secret/secret_driver.c | 168 +++++++++++++++++++++++- src/secret/secrets.conf.in | 14 ++ src/secret/virtsecretd.service.extra.in | 8 ++ src/util/vircrypto.c | 130 +++++++++++++++++- src/util/vircrypto.h | 8 ++ tests/vircryptotest.c | 65 +++++++++ 11 files changed, 420 insertions(+), 4 deletions(-) create mode 100644 src/secret/secrets.conf.in -- 2.51.1

3 15

[PATCH 0/4] selinux: skip fallback label restore for shared media
by Cole Robinson 14 Nov '25

14 Nov '25

https://issues.redhat.com/browse/RHEL-126945 selinux label set/restore has race conditions on qemu:///session, where the xattr label remembering path is not used. See the above issue for a more detailed description of the problem. This series dodges the issue by skipping the fallback label restore for readonly resources like kernel and initrd, basically anything that would get the virt_content_t label. Note, disks already skip _all_ attempts to remember or restore selinux labels if the disk is marked readonly or shareable, and has done so for a long time. Maybe we should extend that out for anything that is inherently readonly or shareable, like kernel + initrd. But for now I stuck with the more conservative approach. And finally, this doesn't actually fix the race condition. If label remembering is working, the refcounting covers us. But if you disable label remembering at the qemu.conf level, there's likely similar issues in the DAC driver even for qemu:///system. I did not look into fixing the race but I suspect it involves keeping the security driver locked until the VM fully boots up. First two patches are not strictly related, but I noticed them while I was in the area Patch 3 adds the plumbing but no behavior change Patch 4 changes behavior Cole Robinson (4): selinux: Match remember/recall arguments for SavedStateLabel selinux: Don't remember labels for shareable SCSI devices selinux: Add is_shared plumbing to RestoreFileLabel selinux: Mark anything using content_context as shared src/security/security_selinux.c | 107 +++++++++++++++++++------------- 1 file changed, 63 insertions(+), 44 deletions(-) -- 2.51.1

2 5

[PATCH] qemu: snapshot: Set umask for 'qemu-img' when creating external inactive snapshots
by Peter Krempa 13 Nov '25

13 Nov '25

From: Peter Krempa <pkrempa(a)redhat.com> External inactive snapshots are created by invoking 'qemu-img' which creates the file. Currently qemu-img creates image with mode 644 based on default umask as libvirt doesn't set any. Having a world-readable image is obviously wrong so set the umask to 0066 to have the file readable only by the owner. Resolves: https://bugs.debian.org/1120119 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_snapshot.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c index d4994dd54e..6868910d9a 100644 --- a/src/qemu/qemu_snapshot.c +++ b/src/qemu/qemu_snapshot.c @@ -228,6 +228,9 @@ qemuSnapshotCreateQcow2Files(virDomainDef *def, NULL))) return -1; + /* ensure that new files are only readable by the user */ + virCommandSetUmask(cmd, 0066); + /* adds cmd line arg: backing_fmt=format,backing_file=/path/to/backing/file */ virBufferAsprintf(&buf, "backing_fmt=%s,backing_file=", virStorageFileFormatTypeToString(defdisk->src->format)); -- 2.51.1

2 2

[PATCH] bhyve: s/provconn/privcon/
by Michal Privoznik 13 Nov '25

13 Nov '25

From: Michal Privoznik <mprivozn(a)redhat.com> Due to a typo, the bhyve driver doesn't compile. Fix it. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Merged as trivial. src/bhyve/bhyve_driver.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/bhyve/bhyve_driver.c b/src/bhyve/bhyve_driver.c index 3a4e83d3d2..4b1ca80fc6 100644 --- a/src/bhyve/bhyve_driver.c +++ b/src/bhyve/bhyve_driver.c @@ -487,7 +487,7 @@ bhyveDomainDefineXMLFlags(virConnectPtr conn, const char *xml, unsigned int flag return NULL; /* Avoid parsing the whole domain definition for ACL checks */ - if (!(def = virDomainDefIDsParseString(xml, provconn->xmlopt, parse_flags))) + if (!(def = virDomainDefIDsParseString(xml, privconn->xmlopt, parse_flags))) return NULL; if (virDomainDefineXMLFlagsEnsureACL(conn, def) < 0) @@ -896,7 +896,7 @@ bhyveDomainCreateXML(virConnectPtr conn, start_flags |= VIR_BHYVE_PROCESS_START_AUTODESTROY; /* Avoid parsing the whole domain definition for ACL checks */ - if (!(def = virDomainDefIDsParseString(xml, provconn->xmlopt, parse_flags))) + if (!(def = virDomainDefIDsParseString(xml, privconn->xmlopt, parse_flags))) return NULL; if (virDomainCreateXMLEnsureACL(conn, def) < 0) -- 2.51.0

1 0

[PATCH v5] qapi: net: deprecate vhostforce option
by Vladimir Sementsov-Ogievskiy 13 Nov '25

13 Nov '25

This option for tap and vhost-user netdevs doesn't make sense since long ago (10 years!), starting from commits: 1e7398a140f7a6 ("vhost: enable vhost without without MSI-X") 24f938a682d934 ("vhost user:support vhost user nic for non msi guests") Prior these commits, to enable kernel vhost-net, or vhost-user-net for some specific kind of guests (that don't have MSI-X support), you should have set vhostforce=on. Now guest type doesn't matter, all guests are equal for these options logic. For tap the current logic is: vhost=on / vhost=off : vhostforce ignored, doesn't make sense vhost unset : vhostforce counts, enabling vhost So you may enable vhost for tap several ways: - vhost=on - vhostforce=on - vhost=on + vhostforce=on - and even vhost=on + vhostforce=off - they are all equal. For vhost-user we simply ignore the vhostforce option at all in the code. Let's finally deprecate the extra options. Also, fix @vhostforce documentation everywhere to show the real picture, and update vhost-user test to not use deprecated option. While updating command line options, drop "experimental" word from "experimental in kernel accelerator". vhost-net is in production for years. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov(a)yandex-team.ru> --- v5: update wording and commit message docs/about/deprecated.rst | 11 +++++++++++ qapi/net.json | 18 ++++++++++++++---- qemu-options.hx | 13 +++++-------- tests/qtest/vhost-user-test.c | 2 +- 4 files changed, 31 insertions(+), 13 deletions(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index dacf2882e4..a781600a2f 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -484,6 +484,17 @@ Stream ``reconnect`` (since 9.2) The ``reconnect`` option only allows specifying second granularity timeouts, which is not enough for all types of use cases, use ``reconnect-ms`` instead. +TAP ``vhostforce`` (since 10.2) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``vhostforce`` option is redundant with the ``vhost`` option. +If they conflict, ``vhost`` takes precedence. Just use ``vhost``. + +Vhost-user ``vhostforce`` (since 10.2) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``vhostforce`` option is a no-op. Do not use it. + CPU device properties ''''''''''''''''''''' diff --git a/qapi/net.json b/qapi/net.json index 60d196afe5..e8ccc8afc2 100644 --- a/qapi/net.json +++ b/qapi/net.json @@ -346,13 +346,18 @@ # @vhostfds: file descriptors of multiple already opened vhost net # devices # -# @vhostforce: vhost on for non-MSIX virtio guests +# @vhostforce: enable vhost-net network accelerator. Ignored when +# @vhost is set. # # @queues: number of queues to be created for multiqueue capable tap # # @poll-us: maximum number of microseconds that could be spent on busy # polling for tap (since 2.7) # +# Features: +# +# @deprecated: Member @vhostforce is deprecated. Use @vhost instead. +# # Since: 1.2 ## { 'struct': 'NetdevTapOptions', @@ -369,7 +374,7 @@ '*vhost': 'bool', '*vhostfd': 'str', '*vhostfds': 'str', - '*vhostforce': 'bool', + '*vhostforce': { 'type': 'bool', 'features': [ 'deprecated' ] }, '*queues': 'uint32', '*poll-us': 'uint32'} } @@ -606,17 +611,22 @@ # # @chardev: name of a unix socket chardev # -# @vhostforce: vhost on for non-MSIX virtio guests (default: false). +# @vhostforce: silently ignored, exists just for backward +# compatibility. # # @queues: number of queues to be created for multiqueue vhost-user # (default: 1) (Since 2.5) # +# Features: +# +# @deprecated: Member @vhostforce is deprecated. +# # Since: 2.1 ## { 'struct': 'NetdevVhostUserOptions', 'data': { 'chardev': 'str', - '*vhostforce': 'bool', + '*vhostforce': { 'type': 'bool', 'features': [ 'deprecated' ] }, '*queues': 'int' } } ## diff --git a/qemu-options.hx b/qemu-options.hx index 0223ceffeb..35a70096e8 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -2882,7 +2882,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, #else "-netdev tap,id=str[,fd=h][,fds=x:y:...:z][,ifname=name][,script=file][,downscript=dfile]\n" " [,br=bridge][,helper=helper][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off]\n" - " [,vhostfd=h][,vhostfds=x:y:...:z][,vhostforce=on|off][,queues=n]\n" + " [,vhostfd=h][,vhostfds=x:y:...:z][,queues=n]\n" " [,poll-us=n]\n" " configure a host TAP network backend with ID 'str'\n" " connected to a bridge (default=" DEFAULT_BRIDGE_INTERFACE ")\n" @@ -2898,9 +2898,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, " default is disabled 'sndbuf=0' to enable flow control set 'sndbuf=1048576')\n" " use vnet_hdr=off to avoid enabling the IFF_VNET_HDR tap flag\n" " use vnet_hdr=on to make the lack of IFF_VNET_HDR support an error condition\n" - " use vhost=on to enable experimental in kernel accelerator\n" - " (only has effect for virtio guests which use MSIX)\n" - " use vhostforce=on to force vhost on for non-MSIX virtio guests\n" + " use vhost=on to enable in kernel accelerator\n" " use 'vhostfd=h' to connect to an already opened vhost net device\n" " use 'vhostfds=x:y:...:z to connect to multiple already opened vhost net devices\n" " use 'queues=n' to specify the number of queues to be created for multiqueue TAP\n" @@ -2991,7 +2989,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev, " use 'start-queue=m' to specify the first queue that should be used\n" #endif #ifdef CONFIG_POSIX - "-netdev vhost-user,id=str,chardev=dev[,vhostforce=on|off]\n" + "-netdev vhost-user,id=str,chardev=dev\n" " configure a vhost-user network, backed by a chardev 'dev'\n" #endif #ifdef __linux__ @@ -3882,12 +3880,11 @@ SRST for insertion into the socket map. The combination of 'map-path' and 'sock-fds' together is not supported. -``-netdev vhost-user,chardev=id[,vhostforce=on|off][,queues=n]`` +``-netdev vhost-user,chardev=id[,queues=n]`` Establish a vhost-user netdev, backed by a chardev id. The chardev should be a unix domain socket backed one. The vhost-user uses a specifically defined protocol to pass vhost ioctl replacement - messages to an application on the other end of the socket. On - non-MSIX guests, the feature can be forced with vhostforce. Use + messages to an application on the other end of the socket. Use 'queues=n' to specify the number of queues to be created for multiqueue vhost-user. diff --git a/tests/qtest/vhost-user-test.c b/tests/qtest/vhost-user-test.c index 609ff24059..a4862d7087 100644 --- a/tests/qtest/vhost-user-test.c +++ b/tests/qtest/vhost-user-test.c @@ -46,7 +46,7 @@ #define QEMU_CMD_SHM " -m %d -object memory-backend-shm,id=mem,size=%dM," \ " -numa node,memdev=mem" #define QEMU_CMD_CHR " -chardev socket,id=%s,path=%s%s" -#define QEMU_CMD_NETDEV " -netdev vhost-user,id=hs0,chardev=%s,vhostforce=on" +#define QEMU_CMD_NETDEV " -netdev vhost-user,id=hs0,chardev=%s" #define HUGETLBFS_MAGIC 0x958458f6 -- 2.48.1

3 3

[PATCH 0/1] cpu_map: fix vmx-* features wrong bitmaps
by Hector Cao 13 Nov '25

13 Nov '25

Hello, I'm unable to make virsh capabilities to detect the right CPU model on an Intel Granite Rapids platform. I would expect the get the CPU model defined in one of the src/cpu_map/x86_GraniteRapids*.xml files. The cause of the wrong detection is the fact that some vmx-* are not correctly detected and considered missing on this platform. When I take a look at the src/cpu_map/x86_features.xml file, I think that some of the vmx-* are wrongly defined. Taking as an example the vmx-apicv-xapic feature, it is defined as the first bit in the EAX register when we read the MSR 0x0000048b . But in Intel specification, this feature is represented as the first bit in the EDX register (32 higher bits). You can find in this submission the patch that fixes this issue, and this for all the affected MSRs. I tested this fix on my Granite Rapids platform and the CPU model is now correctly detected. Hector Cao (1): cpu_map: fix vmx-* features wrong bitmaps src/cpu_map/x86_features.xml | 136 +++++++++++++++++------------------ 1 file changed, 68 insertions(+), 68 deletions(-) -- 2.45.2

4 10

[PATCH 0/2] Remove use of deprecated 'xmlIndentTreeOutput' variable from libxml2
by Peter Krempa 12 Nov '25

12 Nov '25

The default from libxml2 is '1' which we wanted. Thus all use in separate processes is okay, and for the few exceptions (see 2/2) the resulting XML is mis-indented but valid for any app which would override it. Peter Krempa (2): virVBoxSnapshotConfSaveVboxFile: Don't modify deprecated 'xmlIndentTreeOutput' virXMLFormatMetadata: Don't modify deprecated 'xmlIndentTreeOutput' src/util/virxml.c | 10 ---------- src/vbox/vbox_snapshot_conf.c | 5 ----- 2 files changed, 15 deletions(-) -- 2.51.1

3 6

[PATCH 0/4] bhyve: support queue configuration for NVMe disks
by Roman Bogorodskiy 12 Nov '25

12 Nov '25

Roman Bogorodskiy (4): conf: domain_validate: make disk queue configuration driver specific bhyve: support queue configuration for NVMe disks bhyve: domain: refactor bhyveDomainDeviceDefValidate() bhyve: domain: improve disks validation src/bhyve/bhyve_command.c | 16 ++- src/bhyve/bhyve_domain.c | 110 +++++++++++++----- src/conf/domain_validate.c | 12 -- src/qemu/qemu_driver.c | 15 +++ src/qemu/qemu_validate.c | 14 +++ .../bhyvexml2argv-disk-virtio-queue-opts.xml | 23 ++++ .../bhyvexml2argvdata/bhyvexml2argv-nvme.args | 2 +- .../bhyvexml2argvdata/bhyvexml2argv-nvme.xml | 2 +- tests/bhyvexml2argvtest.c | 1 + .../bhyvexml2xmlout-nvme.xml | 2 +- 10 files changed, 148 insertions(+), 49 deletions(-) create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-disk-virtio-queue-opts.xml -- 2.51.0

3 7

[PATCH 0/7] Fixes for CVE-2025-12748
by Martin Kletzander 11 Nov '25

11 Nov '25

ACL checks were performed after parsing a user provided XML in its entirety which could be written in a way that would make libvirt allocate too much memory and crash. Instead parse just the identifiers out of which only name and UUID are needed for ACL checks, perform those and then parse the whole definition. In order not to pass bogus UUID to the ACL functions, rewrite any generated UUID in the first step with a nil UUID since the ACLs cannot be written to expect a particular generated UUID as that would not make sense. If squashing the patches is preferred, let me know. Fixes: CVE-2025-12748 Reported-by: Святослав Терешин <s.tereshin(a)fobos-nt.ru> Martin Kletzander (7): conf: Add virDomainDefIDsParseString bhyve: Check ACLs before parsing the whole domain XML libxl: Check ACLs before parsing the whole domain XML lxc: Check ACLs before parsing the whole domain XML vz: Check ACLs before parsing the whole domain XML ch: Check ACLs before parsing the whole domain XML qemu: Check ACLs before parsing the whole domain XML src/bhyve/bhyve_driver.c | 24 ++++++++--- src/ch/ch_driver.c | 76 +++++++++++++++++++++++---------- src/conf/domain_conf.c | 29 +++++++++++++ src/conf/domain_conf.h | 3 ++ src/libvirt_private.syms | 1 + src/libxl/libxl_driver.c | 20 ++++++--- src/lxc/lxc_driver.c | 22 +++++++--- src/qemu/qemu_driver.c | 90 ++++++++++++++++++++------------------- src/qemu/qemu_migration.c | 21 ++++++++- src/qemu/qemu_migration.h | 4 +- src/qemu/qemu_saveimage.c | 25 +++++++++-- src/qemu/qemu_saveimage.h | 4 +- src/qemu/qemu_snapshot.c | 4 +- src/vz/vz_driver.c | 18 +++++--- 14 files changed, 243 insertions(+), 98 deletions(-) -- 2.51.2

3 14

Does our interface compatibility promise cover defaults?
by Markus Armbruster 11 Nov '25

11 Nov '25

From about/deprecated.rst: In general features are intended to be supported indefinitely once introduced into QEMU. In the event that a feature needs to be removed, it will be listed in this section. The feature will remain functional for the release in which it was deprecated and one further release. After these two releases, the feature is liable to be removed. Deprecated features may also generate warnings on the console when QEMU starts up, or if activated via a monitor command, however, this is not a mandatory requirement. This obviously applies to syntax and semantics of our external interface. Does it apply to default values there? If no: does this mean we can change defaults without notice? If yes: does this mean any change of defaults needs notice in about/deprecated.rst and the grace period? Note that changing a default is a silent change, like changing semantics / behavior, unlike changing syntax.

3 2