September 2023 - Devel - libvirt List Archives

[PATCH v2] lxc: fix lxcContainerMountAllFS() DEREF_BEFORE_CHECK
by Dmitry Frolov 20 Oct '23

20 Oct '23

vmDef->fss[i]->src->path may be NULL, so check is needed before passing it to VIR_DEBUG. Also removed checking vmDef->fss[i]->src for NULL, since it may not be NULL. Fixes: 57487085dc ("lxc: don't try to reference NULL when mounting filesystems") Signed-off-by: Dmitry Frolov <frolov(a)swemel.ru> --- src/lxc/lxc_container.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 21220661f7..9601061b23 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -1467,12 +1467,12 @@ static int lxcContainerMountAllFS(virDomainDef *vmDef, if (STREQ(vmDef->fss[i]->dst, "/")) continue; - VIR_DEBUG("Mounting '%s' -> '%s'", vmDef->fss[i]->src->path, vmDef->fss[i]->dst); + VIR_DEBUG("Mounting '%s' -> '%s'", NULLSTR(vmDef->fss[i]->src->path), vmDef->fss[i]->dst); if (lxcContainerResolveSymlinks(vmDef->fss[i], false) < 0) return -1; - if (!(vmDef->fss[i]->src && vmDef->fss[i]->src->path && + if (!(vmDef->fss[i]->src->path && STRPREFIX(vmDef->fss[i]->src->path, vmDef->fss[i]->dst)) && lxcContainerUnmountSubtree(vmDef->fss[i]->dst, false) < 0) return -1; -- 2.34.1

3 2

[libvirt PATCH] logging: lockdown the systemd service configuration
by Daniel P. Berrangé 20 Oct '23

20 Oct '23

The 'systemd-analyze security' command looks at the unit file configuration and reports on any settings which increase the attack surface for the daemon. Since most systemd units are fairly minimalist, this is generally informing us about settings that we never put any thought into using before. In its current configuration it reports # systemd-analyze security virtlogd.service ...snip... → Overall exposure level for virtlogd.service: 9.6 UNSAFE 😨 which is pretty terrible as a score. If we apply all of the recommendations that appear possible without (knowingly) breaking functionality it reports: # systemd-analyze security virtlogd.service ...snip... → Overall exposure level for virtlogd.service: 2.2 OK 🙂 which is a pretty decent improvement. Some of the settings we would like to enable require a systemd version that is newer than that available in our oldest distro target - RHEL-8 at v239. NB, RestrictSUIDSGID is technically newer than 239, but RHEL-8 backported it, and other distros we target have it by default. Remaining recommendations are ✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) We block FOWNER/IPC_OWNER, but can't block the two DAC capabilities. Historically apps/users might point QEMU to log files in $HOME, pre-created with their own user ID. ✗ IPAddressDeny= Not required since RestrictAddressFamilies blocks IP usage. Ignoring this avoids the overhead of creating a traffic filter than will never be used. ✗ NoNewPrivileges= Highly desirable, but cannot enable it yet, because it will block the ability to transition to the virtlogd_t SELinux domain during execve. The SELinux policy needs fixing to permit this transition under NNP first. ✗ PrivateTmp= There is a decent chance people have VMs configured with a serial port logfile pointing at /tmp. We would cause a regression to use private /tmp for logging ✗ PrivateUsers= This would put virtlogd inside a user namespace where its root is in fact unprivileged. Same problem as the User= setting below ✗ ProcSubset= Libraries we link to might read certain non-PID related files from /proc ✗ ProtectClock= Requires v245 ✗ ProtectHome= Same problem as PrivateTmp=. There's a decent chance that someone has a VM configured to write a logfile to /home ✗ ProtectHostname= Requires v241 ✗ ProtectKernelLogs Requires v244 ✗ ProtectProc Requires v247 ✗ ProtectSystem= We only set it to 'full', as 'strict' is not viable for our required usage ✗ RootDirectory=/RootImage= We are not capable of running inside a custom chroot given needs to write log files to arbitrary places ✗ RestrictAddressFamilies=~AF_UNIX We need AF_UNIX to communicate with other libvirt daemons ✗ SystemCallFilter=~@resources We link to libvirt.so which links to libnuma.so which has a constructor that calls set_mempolicy. This is highly undesirable todo during a constructor. ✗ User=/DynamicUser= This is highly desirable, but we currently read/write logs as root, and directories we're told to write into could be anywhere. So using a non-root user would have a major risk of regressions for applications and also have upgrade implications Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/logging/virtlogd.service.in | 94 +++++++++++++++++++++++++++++++++ 1 file changed, 94 insertions(+) diff --git a/src/logging/virtlogd.service.in b/src/logging/virtlogd.service.in index 8e245ddb43..9e3838ff34 100644 --- a/src/logging/virtlogd.service.in +++ b/src/logging/virtlogd.service.in @@ -20,5 +20,99 @@ OOMScoreAdjust=-900 # per systemd recommendations LimitNOFILE=1024:524288 +CapabilityBoundingSet=~CAP_AUDIT_CONTROL +CapabilityBoundingSet=~CAP_AUDIT_READ +CapabilityBoundingSet=~CAP_AUDIT_WRITE +CapabilityBoundingSet=~CAP_BLOCK_SUSPEND +CapabilityBoundingSet=~CAP_CHOWN +# Mgmt app/user might have pre-created log files that we're +# told to open and write to, or be storing them in otherwise +# inaccessible locations like $HOME. So we need to ignore +# DAC permission checks. +#CapabilityBoundingSet=~CAP_DAC_OVERRIDE +#CapabilityBoundingSet=~CAP_DAC_READ_SEARCH +CapabilityBoundingSet=~CAP_FOWNER +CapabilityBoundingSet=~CAP_FSETID +CapabilityBoundingSet=~CAP_IPC_LOCK +CapabilityBoundingSet=~CAP_IPC_OWNER +CapabilityBoundingSet=~CAP_KILL +CapabilityBoundingSet=~CAP_LEASE +CapabilityBoundingSet=~CAP_LINUX_IMMUTABLE +CapabilityBoundingSet=~CAP_MAC_ADMIN +CapabilityBoundingSet=~CAP_MAC_OVERRIDE +CapabilityBoundingSet=~CAP_MKNOD +CapabilityBoundingSet=~CAP_NET_ADMIN +CapabilityBoundingSet=~CAP_NET_BIND_SERVICE +CapabilityBoundingSet=~CAP_NET_BROADCAST +CapabilityBoundingSet=~CAP_NET_RAW +CapabilityBoundingSet=~CAP_SETFCAP +CapabilityBoundingSet=~CAP_SETPCAP +CapabilityBoundingSet=~CAP_SETGID +CapabilityBoundingSet=~CAP_SETUID +CapabilityBoundingSet=~CAP_SYSLOG +CapabilityBoundingSet=~CAP_SYS_ADMIN +CapabilityBoundingSet=~CAP_SYS_BOOT +CapabilityBoundingSet=~CAP_SYS_CHROOT +CapabilityBoundingSet=~CAP_SYS_MODULE +CapabilityBoundingSet=~CAP_SYS_NICE +CapabilityBoundingSet=~CAP_SYS_PACCT +CapabilityBoundingSet=~CAP_SYS_PTRACE +CapabilityBoundingSet=~CAP_SYS_RAWIO +CapabilityBoundingSet=~CAP_SYS_RESOURCE +CapabilityBoundingSet=~CAP_SYS_TIME +CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG +CapabilityBoundingSet=~CAP_WAKE_ALARM + +LockPersonality=true +MemoryDenyWriteExecute=true +# Cannot enable this as it prevents transitioning to +# the confined SELinux virtlogd_t domain on execve +# unless we modify the policy to allow this. +#NoNewPrivileges=true +PrivateDevices=true +PrivateMounts=true +PrivateNetwork=true +# XXX someone could configure QEMU to log a serial port to an +# arbitrary directory, including /tmp, even if this is ill-advised +#PrivateTmp=true +# Not until oldest build target has systemd >= v245 +#ProtectClock=true +ProtectControlGroups=true +# Not until oldest build target has systemd >= v241 +#ProtectHostname=true +# Not until oldest build target has systemd >= v244 +#ProtectKernelLogs=true +ProtectKernelModules=true +ProtectKernelTunables=true +# Not until oldest build target has systemd >= v247 +#ProtectProc=invisible +ProtectSystem=full +RestrictAddressFamilies=AF_UNIX +RestrictNamespaces=~cgroup +RestrictNamespaces=~ipc +RestrictNamespaces=~mnt +RestrictNamespaces=~net +RestrictNamespaces=~pid +RestrictNamespaces=~user +RestrictNamespaces=~uts +RestrictRealtime=true +RestrictSUIDSGID=true +SystemCallArchitectures=native +SystemCallFilter=~@clock +SystemCallFilter=~@debug +SystemCallFilter=~@module +SystemCallFilter=~@mount +SystemCallFilter=~@raw-io +SystemCallFilter=~@reboot +SystemCallFilter=~@swap +SystemCallFilter=~@privileged +# Unfortunately we link to libnuma via libvirt.so which +# has a constructor that runs unconditionally that invokes +# set_mempolicy() +#SystemCallFilter=~@resources +SystemCallFilter=~@cpu-emulation +SystemCallFilter=~@obsolete +UMask=077 + [Install] Also=virtlogd.socket -- 2.41.0

2 2

[libvirt PATCH 0/7] docs: ci: Update the CI pages with fresh contents
by Erik Skultety 10 Oct '23

10 Oct '23

While we have already descriptive articles on our GitLab CI, there's recently been some work on the CI front where a few sections deserve some updates. Erik Skultety (7): docs: ci-runners: Add a note on a new runner registration process docs: ci: Update the description on the integration CI GitLab variables docs: testtck: Tweak the Avocado command to run TCK test suite docs: testtck: Improve the documentation on how to get a VM from lcitool docs: testing: Adjust the docs on how to run container workloads locally docs: testtck: Add a clear note on libvirt + Perl bindings dependency docs: testtck: Expand the 'Run TCK' section on making use of ci/jobs.sh docs/ci-runners.rst | 10 ++++++++ docs/ci.rst | 8 ++++-- docs/testing.rst | 37 ++++++++++++++++++++++------ docs/testtck.rst | 60 ++++++++++++++++++++++++++++++++++++++------- 4 files changed, 96 insertions(+), 19 deletions(-) -- 2.41.0

2 12

[PATCH] hw/rdma: Deprecate the pvrdma device and the rdma subsystem
by Thomas Huth 05 Oct '23

05 Oct '23

This subsystem is said to be in a bad shape (see e.g. [1], [2] and [3]), and nobody seems to feel responsible to pick up patches for this and send them via a pull request. For example there is a patch for a CVE-worthy bug posted more than half a year ago [4] which has never been merged. Quoting Markus: "Given the shape it is in, I wouldn't let friends use it in production" - we shouldn't expose this to our users in the current state. Thus let's mark it as deprecated and finally remove it unless somebody steps up and improves the code quality and adds proper regression tests. [1] https://lore.kernel.org/qemu-devel/20230918144206.560120-1-armbru@redhat.co… [2] https://lore.kernel.org/qemu-devel/ZQnojJOqoFu73995@redhat.com/ [3] https://lore.kernel.org/qemu-devel/1054981c-e8ae-c676-3b04-eeb030e11f65@tls… [4] https://lore.kernel.org/qemu-devel/20230301142926.18686-1-yuval.shaia.ml@gm… [5] https://lore.kernel.org/qemu-devel/8734z9f086.fsf@pond.sub.org/ Signed-off-by: Thomas Huth <thuth(a)redhat.com> --- MAINTAINERS | 2 +- docs/about/deprecated.rst | 8 ++++++++ hw/rdma/vmw/pvrdma_main.c | 2 ++ 3 files changed, 11 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 355b1960ce..ca42b89ef8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3815,7 +3815,7 @@ F: docs/block-replication.txt PVRDMA M: Yuval Shaia <yuval.shaia.ml(a)gmail.com> M: Marcel Apfelbaum <marcel.apfelbaum(a)gmail.com> -S: Maintained +S: Odd Fixes F: hw/rdma/* F: hw/rdma/vmw/* F: docs/pvrdma.txt diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index dc4da95329..f0c7addb1f 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -365,6 +365,14 @@ QEMU's ``vhost`` feature, which would eliminate the high latency costs under which the 9p ``proxy`` backend currently suffers. However as of to date nobody has indicated plans for such kind of reimplementation unfortunately. +``-device pvrdma`` and the rdma subsystem (since 8.2) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The pvrdma device and the whole rdma subsystem are in a bad shape and +without active maintenance. The QEMU project intends to remove this +device and subsystem from the code base in a future release without +replacement unless somebody steps up and improves the situation. + Block device options '''''''''''''''''''' diff --git a/hw/rdma/vmw/pvrdma_main.c b/hw/rdma/vmw/pvrdma_main.c index 4fc6712025..ed49ce1e72 100644 --- a/hw/rdma/vmw/pvrdma_main.c +++ b/hw/rdma/vmw/pvrdma_main.c @@ -601,6 +601,8 @@ static void pvrdma_realize(PCIDevice *pdev, Error **errp) bool ram_shared = false; PCIDevice *func0; + warn_report_once("pvrdma is deprecated and will be removed in a future release"); + rdma_info_report("Initializing device %s %x.%x", pdev->name, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn)); -- 2.41.0

4 4

The attached virtio disk is not recognized by libvirt but it is recognized by qemu
by Mario Marietto 01 Oct '23

01 Oct '23

Hello. I'm trying to virtualize FreeBSD 13.2 for arm 32 bit on my laptop ARM Chromebook where qemu is version 5.1,KVM is enabled,libvirt and virt-manager are installed from the source code and everything works great. The host OS is Devuan 5. Infact,using these parameters,FreeBSD is able to boot entirely : UEFICODE=/usr/share/AAVMF/AAVMF32_CODE.fd UEFIVARS=/usr/share/AAVMF/AAVMF32_VARS.fd DISK=/Dati/img/FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img qemu-system-arm -enable-kvm -serial stdio -m 1024 -M virt -cpu cortex-a15 -drive if=pflash,format=raw,unit=0,file=$UEFICODE -drive if=pflash,format=raw,unit=1,file=$UEFIVARS -drive file=$DISK,media=disk,format=raw -device i82559b,netdev=net0,mac="52:54:00:12:34:55" -netdev type=user,id=net0 -device virtio-gpu-pci -usb -device nec-usb-xhci -device usb-kbd -device usb-mouse -device vmware-svga,id=video0,vgamem_mb=16 As you can see from this boot log messages : https://pastebin.ubuntu.com/p/VBtJ5bTTCz/ So,this argument is good because qemu recognizes the virtio disk : -drive file=$DISK,media=disk,format=raw \ but these arguments used by libvirt aren't able to boot FreeBSD because the virtio disk attached is not recognized (I also tried with a SATA disk and it is not recognized as well) : <disk type="file" device="disk"> <driver name="qemu" type="raw"/> <source file="/Dati/img/FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img"/> <target dev="vda" bus="virtio"/> <address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/> </disk> Here you can see what are the full XML code used by libirt : https://pastebin.ubuntu.com/p/hpGmgp2773/ this is the portion of code that correspond with the virtio disk (the FreeBSD image file) [image: 1] <https://i.stack.imgur.com/NUWg7.png> What's the difference between the qemu and the libvirt parameters ? Do you have some vague idea about the reason ? I think the problem is caused by qemu and/or libvirt. I tried to boot the image going inside the bios settings and trying to boot directly the image disk,but I saw this error : [image: 2] <https://i.stack.imgur.com/rdYGs.png> If you want to see the whole boot sequence,you can give a look at this short video that I have recorded : https://drive.google.com/file/d/1kRoAFH_6DH-vNEmNmg4PEQ8lQmKZnUi2/view -- Mario.

1 0

[libvirt PATCH] qemu: DomainGetGuestVcpusParams: reduce scope of tmp
by Ján Tomko 29 Sep '23

29 Sep '23

Wrap the macro body in a new block and move the declaration of 'tmp' into it, to avoid the need to mix g_autofree with manual freeing. Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- src/qemu/qemu_driver.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 056b5cec98..f3c9730cd8 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -18396,7 +18396,6 @@ qemuDomainGetGuestVcpusParams(virTypedParameterPtr *params, g_autoptr(virBitmap) vcpus = virBitmapNew(QEMU_GUEST_VCPU_MAX_ID); g_autoptr(virBitmap) online = virBitmapNew(QEMU_GUEST_VCPU_MAX_ID); g_autoptr(virBitmap) offlinable = virBitmapNew(QEMU_GUEST_VCPU_MAX_ID); - g_autofree char *tmp = NULL; size_t i; int ret = -1; @@ -18416,11 +18415,13 @@ qemuDomainGetGuestVcpusParams(virTypedParameterPtr *params, } #define ADD_BITMAP(name) \ - if (!(tmp = virBitmapFormat(name))) \ - goto cleanup; \ - if (virTypedParamsAddString(&par, &npar, &maxpar, #name, tmp) < 0) \ - goto cleanup; \ - VIR_FREE(tmp) + do { \ + g_autofree char *tmp = NULL; \ + if (!(tmp = virBitmapFormat(name))) \ + goto cleanup; \ + if (virTypedParamsAddString(&par, &npar, &maxpar, #name, tmp) < 0) \ + goto cleanup; \ + } while (0) ADD_BITMAP(vcpus); ADD_BITMAP(online); -- 2.41.0

2 1

Fwd: Hexdump0815 support for kvm and an important question (Was: Re: New thread...)
by Mario Marietto 29 Sep '23

29 Sep '23

Hello to everyone. I'm trying to virtualize FreeBSD 13.2 for arm 32 bit on my laptop ARM Chromebook where KVM is enabled,libvirt and virt-manager are installed from the source code and everything work great. The Host OS is Devuan 5. Infact , using these qemu parameters,FreeBSD is able to boot entirely : DISK=/Dati/img/FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img qemu-system-arm \ -enable-kvm -serial stdio \ -m 1024 -M virt -cpu cortex-a15 \ -drive if=pflash,format=raw,unit=0,file=$UEFICODE \ -drive if=pflash,format=raw,unit=1,file=$UEFIVARS \ -drive file=$DISK,media=disk,format=raw \ -device i82559b,netdev=net0,mac="52:54:00:12:34:55" \ -netdev type=user,id=net0 \ -device virtio-gpu-pci \ -usb -device nec-usb-xhci \ -device usb-kbd -device usb-mouse \ -device vmware-svga,id=video0,vgamem_mb=16 *As you can see from this boot log messages :* https://pastebin.ubuntu.com/p/DWggdRRxVv/ *So,this argument is good :* -drive file=$DISK,media=disk,format=raw \ *but these arguments used by libvirt aren't able to boot FreeBSD because the virtio disk attached is not recognized (I also tried with a SATA disk and it is not regognized as well) :* <disk type="file" device="disk"> <driver name="qemu" type="raw"/> <source file="/Dati/img/FreeBSD-13.2-RELEASE-arm-armv7-GENERICSD.img"/> <target dev="vda" bus="virtio"/> <address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/> </disk> *as you can see :* [image: Screenshot_2023-09-29_10-44-06.png] What's the difference ? Do you have some vague idea about the reason ? I don't know if the cause is related to libvirt or to FreeBSD,so I'm trying to exclude one of these. -- Mario.

1 1

[PATCH] qemu: Add VIR_FREE in ADD_BITMAP
by Anastasia Belova 29 Sep '23

29 Sep '23

virBitmapFormat returns the string that should be freed. All strings in three ADD_BITMAP calls in qemuDomainGetGuestVcpusParams are contained in tmp. So memory leak is possible here without VIR_FREE. Fixes: 3e7db8d3e8 ("Remove backslash alignment attempts") Signed-off-by: Anastasia Belova <abelova(a)astralinux.ru> --- src/qemu/qemu_driver.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 9e0f204e44..a70bfb6450 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -18420,6 +18420,7 @@ qemuDomainGetGuestVcpusParams(virTypedParameterPtr *params, goto cleanup; \ if (virTypedParamsAddString(&par, &npar, &maxpar, #name, tmp) < 0) \ goto cleanup; \ + VIR_FREE(tmp); \ ADD_BITMAP(vcpus); ADD_BITMAP(online); -- 2.30.2

3 2

[PATCH] NEWS: Document my contributions for upcoming release
by Michal Privoznik 29 Sep '23

29 Sep '23

Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- NEWS.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index c17a1d002d..6f46e86ba8 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -43,8 +43,20 @@ v9.8.0 (unreleased) stability of qemu. Therefore, when available, libvirt will use nbdkit as a backend for these network disks and export an NBD disk to qemu. + * virnetdevopenvswitch: Propagate OVS error messages + + When configuring OVS interfaces/bridges libvirt used to report its own + error messages instead of passing (more accurate) error messages from + `ovs-vsctl`. This is now changed. + * **Bug fixes** + * Various virtio-mem/virtio-pmem fixes + + It was discovered that libvirt did not validate some values wrt virtio-mem + and virtio-pmem memory devices, e.g. overlapping memory addresses or + alignment. + v9.7.0 (2023-09-01) =================== -- 2.41.0

2 1

[PATCH] NEWS: Fix placement of network metadata entry
by Michal Privoznik 29 Sep '23

29 Sep '23

The network metadata support is a new feature in the upcoming release, not a removed one. Place it accordingly. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- NEWS.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/NEWS.rst b/NEWS.rst index 768e6fc326..c17a1d002d 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -15,14 +15,14 @@ v9.8.0 (unreleased) * **Removed features** +* **New features** + * network: New metadata change event The network object now has a new event ID ``VIR_NETWORK_EVENT_ID_METADATA_CHANGE`` that can be used to get notifications upon changes in any of ``<title>``, ``<description>`` or ``<metadata>``. -* **New features** - * qemu: Add support for vDPA block devices With a new enough version of qemu, libvirt will allow you to assign vDPA block -- 2.41.0

2 1