October 2024 - Devel - libvirt List Archives

[PATCH v5 0/6] Add TPM emulator <source type='file/dir' path='..'/>
by marcandre.lureau＠redhat.com 06 Nov '24

06 Nov '24

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Hi, When swtpm capabilities reports "nvram-backend-dir", it can accepts a single file or block device where TPM state will be stored. --tpmstate must be backend-uri=file://. v5: - fix indentation - update doc about state sharing/locking - add r-b from Stefan v4: - add "qemu: explicit swtpm state locking" - add r-b from Stefan, first patch only atm v3: - changed to <source type='file/dir' path='..'/> v2: - add <source dir='..'/> support as well (Daniel) Related: https://issues.redhat.com/browse/CNV-35250 Marc-André Lureau (6): util: check swtpm nvram-backend-{dir,file} capabilities tpm: rename 'storagepath' to 'source_path' schema: add TPM emulator <source type='file' path='..'> schema: add TPM emulator <source type='dir' path='..'> qemu_tpm: handle file/block storage source qemu: explicit swtpm state locking docs/formatdomain.rst | 22 ++++ src/conf/domain_conf.c | 31 ++++- src/conf/domain_conf.h | 12 +- src/conf/schemas/domaincommon.rng | 26 ++++ src/qemu/qemu_tpm.c | 114 +++++++++++++----- src/security/security_selinux.c | 6 +- src/util/virtpm.c | 3 + src/util/virtpm.h | 3 + .../qemuxmlconfdata/tpm-emulator-tpm2-enc.xml | 1 + tests/qemuxmlconfdata/tpm-emulator-tpm2.xml | 1 + tests/testutilsqemu.c | 1 + 11 files changed, 187 insertions(+), 33 deletions(-) -- 2.47.0

4 10

[PATCH v2] network: add rule to nftables backend that zeroes checksum of DHCP responses
by Laine Stump 05 Nov '24

05 Nov '24

Many long years ago (April 2010), soon after "vhost" in-kernel packet processing was added to the virtio-net driver, people running RHEL5 virtual machines with a virtio-net interface connected via a libvirt virtual network noticed that when vhost packet processing was enabled, their VMs could no longer get an IP address via DHCP - the guest was ignoring the DHCP response packets sent by the host. (I've been informed by danpb that the same issue had been encountered, and "fixed" even earlier than that, in 2006, with Xen as the hypervisor.) The "gory details" of the 2010 discussion are chronicled here: https://lists.isc.org/pipermail/dhcp-hackers/2010-April/001835.html but basically it was because the checksum of packets wasn't being fully computed on the host side (because QEMU on the host and the NIC driver in the guest had agreed between themselves to turn off checksums because they were unnecessary due to the "link" between the two being entirely in local memory and not a physical cable), but 1) a partial checksum had been put into the packets at some point by "someone" 2) the "don't use checksums" info was known by the guest kernel, which would properly ignore the "bad" checksum), and 3) the packets were being read by the dhclient application on the guest side with a "raw" socket (thus bypassing the guest kernel UDP processing that would have known the checksum was irrelevant)), The "fix" for this ended up being two-tiered: 1) The ISC DHCP package (which contains the aforementioned dhclient program) made a fix to their dhclient code which caused it to accept packets anyway even if they didn't have a proper checksum (NB: that's not a full explanation, and possibly not accurate). This fixed the problem for guests with an updated dhclient. Here is the code with the fix to ISC DHCP: https://github.com/isc-projects/dhcp/blob/master/common/packet.c#L365 This fixed the issue for any new/updated guests that had the fixed dhclient, but it didn't solve the problem for existing/old guest images that didn't/couldn't get their dhclient updated. This brings us to: 2) iptables added a new "CHECKSUM" target and "--checksum-fill" action: http://patchwork.ozlabs.org/patch/58525/ and libvirt added an iptables rule for each virtual network to match DHCP response packets and perform --checksum-fill. This way by the time dhclient on the guest reads the raw packet, the checksum would be corrected, and the packet would be accepted. This was pushed upstream in libvirt commit v0.8.2-142-gfd5b15ff1a. The word at the time from those more knowledgeable than me was that the bad checksum problem was really specific to ISC's dhclient running on Linux, and so once their fix was in use everywhere dhclient was used, bad checksums would be a thing of the past and the --checksum-fill iptables rules would no longer be needed (but would otherwise be harmless if they were still there). (Plot twist: the dhclient code in fix (1) above apparently is on a Linux-only code path - this is very important later!) Based on this information (and also due to the opinion that fixing it by having iptables modify the packet checksum was really the wrong way to permanently fix things, i.e. an "ugly hack"), the nftables developers made the decision to not implement an equivalent to --checksum-fill in nftables. As a result, when I wrote the nftables firewall backend for libvirt virtual networks earlier this year, it didn't add in any rule to "fix" broken UDP checksums (since there was apparently no equivalent in nftables and, after all, that was fixed somewhere else 14 years ago, right???) But last week, when Rich Jones was doing routine testing using a Fedora 40 host (the first Fedora release to use the nftables backend of libvirt's network driver by default) and a FreeBSD guest, for "some strange reason", the FreeBSD guest was unable to get an IP address from DHCP!! https://www.spinics.net/linux/fedora/libvirt-users/msg14356.html A few quick tests proved that it was the same old "bad checksum" problem from 2010 come back to haunt us - it wasn't a Linux-only issue after all. Phil Sutter and Eric Garver (nftables people) pointed out that, while nftables doesn't have an action that will *compute* the checksum of a packet, it *does* have an action that will set the checksum to 0, and suggested we try adding a "zero the checksum" rule for dhcp response packets to our nftables ruleset. (Why? Because a checksum value of 0 in a IPv4 UDP packet is defined by RFC768 to mean "no checksum generated", implying "checksum not needed"). It turns out that this works - dhclient properly recognizes that a 0 checksum means "don't bother with the checksum", and accepts the packet as valid. So to once again fix this timeless bug, this patch adds such a checksum zeroing rule to the nftables rules setup for each virtual network. This has been verified (on a Fedora 40 host) to fix DHCP with FreeBSD guests, while not breaking it for Fedora or Windows (10) guests. Fixes: b89c4991daa0ee9371f10937fab3b03c5ffdabc6 Reported-by: Rich Jones <rjones(a)redhat.com> Fix-Suggested-by: Eric Garver <egarver(a)redhat.com> Fix-Suggested-by: Phil Sutter <psutter(a)redhat.com> Signed-off-by: Laine Stump <laine(a)redhat.com> Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com> --- (NB: jdenemar reminded me this is a bugfix, so we don't need to rush to get it pushed before he freezes for the RC1 snapshot. I'm happy with it as is though, if anyone is awake early enough and wants to push it before he snapshots RC1. Otherwise I'll just push it later and it will be in RC2) Changes from V1: * informational errors/omissions in commit log message fixed src/network/network_nftables.c | 69 +++++++++++++++++++ tests/networkxml2firewalldata/base.nftables | 14 ++++ .../forward-dev-linux.nftables | 16 +++++ .../isolated-linux.nftables | 16 +++++ .../nat-default-linux.nftables | 16 +++++ .../nat-ipv6-linux.nftables | 16 +++++ .../nat-ipv6-masquerade-linux.nftables | 16 +++++ .../nat-many-ips-linux.nftables | 16 +++++ .../nat-port-range-ipv6-linux.nftables | 16 +++++ .../nat-port-range-linux.nftables | 16 +++++ .../nat-tftp-linux.nftables | 16 +++++ .../route-default-linux.nftables | 16 +++++ 12 files changed, 243 insertions(+) diff --git a/src/network/network_nftables.c b/src/network/network_nftables.c index f8b5ab665d..5523207269 100644 --- a/src/network/network_nftables.c +++ b/src/network/network_nftables.c @@ -51,6 +51,7 @@ VIR_LOG_INIT("network.nftables"); #define VIR_NFTABLES_FWD_OUT_CHAIN "guest_output" #define VIR_NFTABLES_FWD_X_CHAIN "guest_cross" #define VIR_NFTABLES_NAT_POSTROUTE_CHAIN "guest_nat" +#define VIR_NFTABLES_MANGLE_POSTROUTE_CHAIN "postroute_mangle" /* we must avoid using the standard "filter" table as used by * iptables, as any subsequent attempts to use iptables commands will @@ -106,6 +107,10 @@ nftablesGlobalChain nftablesChains[] = { /* chains for NAT rules */ {NULL, VIR_NFTABLES_NAT_POSTROUTE_CHAIN, "{ type nat hook postrouting priority 100; policy accept; }"}, + + /* chain for "mangle" rules that modify packets (e.g. 0 out UDP checksums) */ + {NULL, VIR_NFTABLES_MANGLE_POSTROUTE_CHAIN, "{ type filter hook postrouting priority 0; policy accept; }"}, + }; @@ -644,6 +649,44 @@ nftablesAddDontMasquerade(virFirewall *fw, } +/** + * nftablesAddOutputFixUdpChecksum: + * + * Add a rule to @fw that will 0 out the checksum of udp packets + * output from @iface with destination port @port. + + * Zeroing the checksum of a UDP packet tells the receiving end "you + * don't need to validate the checksum", which is useful in cases + * where the host (sender) thinks that packet checksums will be + * computed elsewhere (and so leaves a partially computed checksum in + * the packet header) while the guest (receiver) thinks that the + * checksum has already been fully computed; in the meantime none of + * the code in between has actually finished computing the + * checksum. + * + * An example of this is DHCP response packets from host to + * guest. If the checksum of each of these packets isn't zeroed, then + * many guests (e.g. FreeBSD) will drop them with reason BAD CHECKSUM; + * if the packets arrive at those guests with a checksum of 0, they + * will happily accept the packet. + */ +static void +nftablesAddOutputFixUdpChecksum(virFirewall *fw, + const char *iface, + int port) +{ + g_autofree char *portstr = g_strdup_printf("%d", port); + + virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4, + "insert", "rule", "ip", + VIR_NFTABLES_PRIVATE_TABLE, + VIR_NFTABLES_MANGLE_POSTROUTE_CHAIN, + "oif", iface, "udp", "dport", portstr, + "counter", "udp", "checksum", "set", "0", + NULL); +} + + static const char networkLocalMulticastIPv4[] = "224.0.0.0/24"; static const char networkLocalMulticastIPv6[] = "ff02::/16"; static const char networkLocalBroadcast[] = "255.255.255.255/32"; @@ -901,6 +944,30 @@ nftablesAddGeneralFirewallRules(virFirewall *fw, } +static void +nftablesAddChecksumFirewallRules(virFirewall *fw, + virNetworkDef *def) +{ + size_t i; + virNetworkIPDef *ipv4def; + + /* Look for the first IPv4 address that has dhcp or tftpboot + * defined. We support dhcp config on 1 IPv4 interface only. + */ + for (i = 0; (ipv4def = virNetworkDefGetIPByIndex(def, AF_INET, i)); i++) { + if (ipv4def->nranges || ipv4def->nhosts) + break; + } + + /* If we are doing local DHCP service on this network, add a rule + * that will fixup the checksum of DHCP response packets back to + * the guests. + */ + if (ipv4def) + nftablesAddOutputFixUdpChecksum(fw, def->bridge, 68); +} + + static int nftablesAddIPSpecificFirewallRules(virFirewall *fw, virNetworkDef *def, @@ -952,6 +1019,8 @@ nftablesAddFirewallRules(virNetworkDef *def, virFirewall **fwRemoval) return -1; } + nftablesAddChecksumFirewallRules(fw, def); + if (virFirewallApply(fw) < 0) return -1; diff --git a/tests/networkxml2firewalldata/base.nftables b/tests/networkxml2firewalldata/base.nftables index a064318739..6371fc12dd 100644 --- a/tests/networkxml2firewalldata/base.nftables +++ b/tests/networkxml2firewalldata/base.nftables @@ -68,6 +68,13 @@ libvirt_network \ guest_nat \ '{ type nat hook postrouting priority 100; policy accept; }' nft \ +add \ +chain \ +ip \ +libvirt_network \ +postroute_mangle \ +'{ type filter hook postrouting priority 0; policy accept; }' +nft \ list \ table \ ip6 \ @@ -136,3 +143,10 @@ ip6 \ libvirt_network \ guest_nat \ '{ type nat hook postrouting priority 100; policy accept; }' +nft \ +add \ +chain \ +ip6 \ +libvirt_network \ +postroute_mangle \ +'{ type filter hook postrouting priority 0; policy accept; }' diff --git a/tests/networkxml2firewalldata/forward-dev-linux.nftables b/tests/networkxml2firewalldata/forward-dev-linux.nftables index 8badb74beb..9dea1a88a4 100644 --- a/tests/networkxml2firewalldata/forward-dev-linux.nftables +++ b/tests/networkxml2firewalldata/forward-dev-linux.nftables @@ -156,3 +156,19 @@ daddr \ 224.0.0.0/24 \ counter \ return +nft \ +-ae insert \ +rule \ +ip \ +libvirt_network \ +postroute_mangle \ +oif \ +virbr0 \ +udp \ +dport \ +68 \ +counter \ +udp \ +checksum \ +set \ +0 diff --git a/tests/networkxml2firewalldata/isolated-linux.nftables b/tests/networkxml2firewalldata/isolated-linux.nftables index d1b4dac178..67ee0a2bf5 100644 --- a/tests/networkxml2firewalldata/isolated-linux.nftables +++ b/tests/networkxml2firewalldata/isolated-linux.nftables @@ -62,3 +62,19 @@ oif \ virbr0 \ counter \ accept +nft \ +-ae insert \ +rule \ +ip \ +libvirt_network \ +postroute_mangle \ +oif \ +virbr0 \ +udp \ +dport \ +68 \ +counter \ +udp \ +checksum \ +set \ +0 diff --git a/tests/networkxml2firewalldata/nat-default-linux.nftables b/tests/networkxml2firewalldata/nat-default-linux.nftables index 28508292f9..951a5a6d60 100644 --- a/tests/networkxml2firewalldata/nat-default-linux.nftables +++ b/tests/networkxml2firewalldata/nat-default-linux.nftables @@ -142,3 +142,19 @@ daddr \ 224.0.0.0/24 \ counter \ return +nft \ +-ae insert \ +rule \ +ip \ +libvirt_network \ +postroute_mangle \ +oif \ +virbr0 \ +udp \ +dport \ +68 \ +counter \ +udp \ +checksum \ +set \ +0 diff --git a/tests/networkxml2firewalldata/nat-ipv6-linux.nftables b/tests/networkxml2firewalldata/nat-ipv6-linux.nftables index d8a9ba706d..617ed8b753 100644 --- a/tests/networkxml2firewalldata/nat-ipv6-linux.nftables +++ b/tests/networkxml2firewalldata/nat-ipv6-linux.nftables @@ -200,3 +200,19 @@ oif \ virbr0 \ counter \ accept +nft \ +-ae insert \ +rule \ +ip \ +libvirt_network \ +postroute_mangle \ +oif \ +virbr0 \ +udp \ +dport \ +68 \ +counter \ +udp \ +checksum \ +set \ +0 diff --git a/tests/networkxml2firewalldata/nat-ipv6-masquerade-linux.nftables b/tests/networkxml2firewalldata/nat-ipv6-masquerade-linux.nftables index a7f09cda59..a710d0e296 100644 --- a/tests/networkxml2firewalldata/nat-ipv6-masquerade-linux.nftables +++ b/tests/networkxml2firewalldata/nat-ipv6-masquerade-linux.nftables @@ -272,3 +272,19 @@ daddr \ ff02::/16 \ counter \ return +nft \ +-ae insert \ +rule \ +ip \ +libvirt_network \ +postroute_mangle \ +oif \ +virbr0 \ +udp \ +dport \ +68 \ +counter \ +udp \ +checksum \ +set \ +0 diff --git a/tests/networkxml2firewalldata/nat-many-ips-linux.nftables b/tests/networkxml2firewalldata/nat-many-ips-linux.nftables index b826fe6134..0be5fb7e65 100644 --- a/tests/networkxml2firewalldata/nat-many-ips-linux.nftables +++ b/tests/networkxml2firewalldata/nat-many-ips-linux.nftables @@ -366,3 +366,19 @@ daddr \ 224.0.0.0/24 \ counter \ return +nft \ +-ae insert \ +rule \ +ip \ +libvirt_network \ +postroute_mangle \ +oif \ +virbr0 \ +udp \ +dport \ +68 \ +counter \ +udp \ +checksum \ +set \ +0 diff --git a/tests/networkxml2firewalldata/nat-port-range-ipv6-linux.nftables b/tests/networkxml2firewalldata/nat-port-range-ipv6-linux.nftables index ceaed6fa40..7574356855 100644 --- a/tests/networkxml2firewalldata/nat-port-range-ipv6-linux.nftables +++ b/tests/networkxml2firewalldata/nat-port-range-ipv6-linux.nftables @@ -384,3 +384,19 @@ daddr \ ff02::/16 \ counter \ return +nft \ +-ae insert \ +rule \ +ip \ +libvirt_network \ +postroute_mangle \ +oif \ +virbr0 \ +udp \ +dport \ +68 \ +counter \ +udp \ +checksum \ +set \ +0 diff --git a/tests/networkxml2firewalldata/nat-port-range-linux.nftables b/tests/networkxml2firewalldata/nat-port-range-linux.nftables index 1dc37a26ec..127536e4db 100644 --- a/tests/networkxml2firewalldata/nat-port-range-linux.nftables +++ b/tests/networkxml2firewalldata/nat-port-range-linux.nftables @@ -312,3 +312,19 @@ oif \ virbr0 \ counter \ accept +nft \ +-ae insert \ +rule \ +ip \ +libvirt_network \ +postroute_mangle \ +oif \ +virbr0 \ +udp \ +dport \ +68 \ +counter \ +udp \ +checksum \ +set \ +0 diff --git a/tests/networkxml2firewalldata/nat-tftp-linux.nftables b/tests/networkxml2firewalldata/nat-tftp-linux.nftables index 28508292f9..951a5a6d60 100644 --- a/tests/networkxml2firewalldata/nat-tftp-linux.nftables +++ b/tests/networkxml2firewalldata/nat-tftp-linux.nftables @@ -142,3 +142,19 @@ daddr \ 224.0.0.0/24 \ counter \ return +nft \ +-ae insert \ +rule \ +ip \ +libvirt_network \ +postroute_mangle \ +oif \ +virbr0 \ +udp \ +dport \ +68 \ +counter \ +udp \ +checksum \ +set \ +0 diff --git a/tests/networkxml2firewalldata/route-default-linux.nftables b/tests/networkxml2firewalldata/route-default-linux.nftables index 282c9542a5..be9c4f5439 100644 --- a/tests/networkxml2firewalldata/route-default-linux.nftables +++ b/tests/networkxml2firewalldata/route-default-linux.nftables @@ -56,3 +56,19 @@ oif \ virbr0 \ counter \ accept +nft \ +-ae insert \ +rule \ +ip \ +libvirt_network \ +postroute_mangle \ +oif \ +virbr0 \ +udp \ +dport \ +68 \ +counter \ +udp \ +checksum \ +set \ +0 -- 2.47.0

4 28

[PATCH] qemu: Fix maximum physical address size in baseline CPU
by Jiri Denemark 31 Oct '24

31 Oct '24

We should include maximum physical address size in the CPU definition created by virConnectBaselineHypervisorCPU only if we know the value for all input CPUs. Otherwise we would create a CPU definition that is not usable on all hosts from which we gathered the CPU info. https://issues.redhat.com/browse/RHEL-24850 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_driver.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 72211da137..72a9542c0b 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -11914,10 +11914,12 @@ qemuConnectBaselineHypervisorCPU(virConnectPtr conn, goto cleanup; for (i = 0; i < ncpus; i++) { - if (!cpus[i]->addr || cpus[i]->addr->limit == 0) + if (!cpus[i]->addr || cpus[i]->addr->limit == 0) { + physAddrSize = 0; continue; + } - if (physAddrSize == 0 || cpus[i]->addr->limit < physAddrSize) + if (i == 0 || cpus[i]->addr->limit < physAddrSize) physAddrSize = cpus[i]->addr->limit; } -- 2.47.0

2 1

[Call for Presentations] FOSDEM 2025: Virt & IaaS devroom
by Kashyap Chamarthy 31 Oct '24

31 Oct '24

(Cross-posted to KVM, Rust-VMM, QEMU, and libvirt lists.) Hi, The CFP for the 'Virt & IaaS' (Infrastructure as a Service) 2025 "devroom" is out[+]. - Where? — Brussels, Belgium - When? — 02 Feb (Sunday) 2025 - Talk submission deadline — 01 Dec 2024 (The CFP submission on the FOSDEM list[+] says 08 Dec 2024 is the submission deadline in its intro paragraph. But I clarified it with Piotr Kliczewski, the deddline is *01* Dec 2024 and _not_ 08th Dec; I updated it below.) ======================================================================== This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM, and Foreman. We invite everyone involved in these fields to submit your proposals by December *1st* 2024. Important Dates --------------- Submission deadline: 1st December 2024 Acceptance notifications: 10th December 2024 Final schedule announcement: 15th December 2024 Devroom: 2nd February 2025 About the Devroom ----------------- The Virtualization & IaaS devroom will feature session topics such as open source hypervisors or virtual machine managers such as Xen Project, KVM, bhyve and VirtualBox as well as Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Submit Your Proposal -------------------- All submissions must be made via the Pretalx event planning site[1]. It is a new submission system so you will need to create an account. If you submitted proposals for FOSDEM in previous years, you won’t be able to use your existing account. During submission please make sure to select Virtualization and Cloud infrastructure from the Track list. Please provide a meaningful abstract and description of your proposed session. Submission Guidelines --------------------- We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Code of Conduct --------------- Following the release of the updated code of conduct for FOSDEM[3], we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Questions? ---------- If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] https://fosdem.org/submit [2] virtualization-devroom-manager at fosdem.org [3] https://fosdem.org/2025/practical/conduct/ ======================================================================== [+] https://lists.fosdem.org/pipermail/fosdem/2024q4/003574.html -- /kashyap

1 0

[PATCH] spec: Fix attributes for ghosts directories in %{_rundir}
by Jiri Denemark 31 Oct '24

31 Oct '24

Directories which we dynamically create in %{_rundir} with non-default attributes (i.e., the owner differs from root:root and/or mode is not 755) fail RPM verification. We should properly declare the expected ownership and mode in the specfile. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- libvirt.spec.in | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index d54d2a1e3e..69693f4851 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -2038,7 +2038,7 @@ exit 0 %config(noreplace) %{_sysconfdir}/sasl2/libvirt.conf %dir %{_datadir}/libvirt/ %ghost %dir %{_rundir}/libvirt/ -%ghost %dir %{_rundir}/libvirt/common/ +%ghost %dir %attr(0700, root, root) %{_rundir}/libvirt/common/ %dir %attr(0755, root, root) %{_localstatedir}/lib/libvirt/ %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/images/ %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/filesystems/ @@ -2124,7 +2124,7 @@ exit 0 %{_unitdir}/virtinterfaced-ro.socket %{_unitdir}/virtinterfaced-admin.socket %attr(0755, root, root) %{_sbindir}/virtinterfaced -%ghost %dir %{_rundir}/libvirt/interface/ +%ghost %dir %attr(0700, root, root) %{_rundir}/libvirt/interface/ %{_libdir}/libvirt/connection-driver/libvirt_driver_interface.so %{_mandir}/man8/virtinterfaced.8* @@ -2166,7 +2166,7 @@ exit 0 %{_unitdir}/virtnodedevd-ro.socket %{_unitdir}/virtnodedevd-admin.socket %attr(0755, root, root) %{_sbindir}/virtnodedevd -%ghost %dir %{_rundir}/libvirt/nodedev/ +%ghost %dir %attr(0700, root, root) %{_rundir}/libvirt/nodedev/ %{_libdir}/libvirt/connection-driver/libvirt_driver_nodedev.so %{_mandir}/man8/virtnodedevd.8* @@ -2181,8 +2181,8 @@ exit 0 %attr(0755, root, root) %{_sbindir}/virtnwfilterd %dir %attr(0700, root, root) %{_sysconfdir}/libvirt/nwfilter/ %ghost %dir %{_rundir}/libvirt/network/ -%ghost %dir %{_rundir}/libvirt/nwfilter-binding/ -%ghost %dir %{_rundir}/libvirt/nwfilter/ +%ghost %dir %attr(0700, root, root) %{_rundir}/libvirt/nwfilter-binding/ +%ghost %dir %attr(0700, root, root) %{_rundir}/libvirt/nwfilter/ %{_libdir}/libvirt/connection-driver/libvirt_driver_nwfilter.so %{_mandir}/man8/virtnwfilterd.8* @@ -2196,7 +2196,7 @@ exit 0 %{_unitdir}/virtsecretd-admin.socket %attr(0755, root, root) %{_sbindir}/virtsecretd %dir %attr(0700, root, root) %{_sysconfdir}/libvirt/secrets/ -%ghost %dir %{_rundir}/libvirt/secrets/ +%ghost %dir %attr(0700, root, root) %{_rundir}/libvirt/secrets/ %{_libdir}/libvirt/connection-driver/libvirt_driver_secret.so %{_mandir}/man8/virtsecretd.8* @@ -2275,11 +2275,11 @@ exit 0 %config(noreplace) %{_sysconfdir}/libvirt/qemu.conf %config(noreplace) %{_sysconfdir}/libvirt/qemu-lockd.conf %config(noreplace) %{_sysconfdir}/logrotate.d/libvirtd.qemu -%ghost %dir %{_rundir}/libvirt/qemu/ -%ghost %dir %{_rundir}/libvirt/qemu/dbus/ -%ghost %dir %{_rundir}/libvirt/qemu/passt/ -%ghost %dir %{_rundir}/libvirt/qemu/slirp/ -%ghost %dir %{_rundir}/libvirt/qemu/swtpm/ +%ghost %dir %attr(0770, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/ +%ghost %dir %attr(0770, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/dbus/ +%ghost %dir %attr(0770, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/passt/ +%ghost %dir %attr(0770, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/slirp/ +%ghost %dir %attr(0770, %{qemu_user}, %{qemu_group}) %{_rundir}/libvirt/qemu/swtpm/ %dir %attr(0751, %{qemu_user}, %{qemu_group}) %{_localstatedir}/lib/libvirt/qemu/ %dir %attr(0751, %{qemu_user}, %{qemu_group}) %{_localstatedir}/lib/libvirt/qemu/checkpoint/ %dir %attr(0751, %{qemu_user}, %{qemu_group}) %{_localstatedir}/lib/libvirt/qemu/dump/ -- 2.47.0

2 1

Entering freeze for libvirt-10.9.0
by Jiri Denemark 30 Oct '24

30 Oct '24

I have just tagged v10.9.0-rc1 in the repository and pushed signed tarballs to https://download.libvirt.org/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible. If you have not done so yet, please update NEWS.rst to document any significant change you made since the last release. Thanks, Jirka

1 1

[PATCH] docs: domain: Be more upfront about 'sgio' not being actually supported
by Peter Krempa 30 Oct '24

30 Oct '24

The support for the 'sgio' attribute for SCSI-backed devices was dropped as there wasn't really ever any upstream support for it. The docs do state that support for this depends on the hypervisor itself, but we can be more clear that there is no hypervisor which does support it. There is also a suggestion to use 'sgio' instead of 'rawio' as being more "secure" but since it no longer works drop this suggestion. Resolves: https://issues.redhat.com/browse/RHEL-65268 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- docs/formatdomain.rst | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 3253a28e5a..d16e00661a 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -2767,14 +2767,13 @@ paravirtualized driver is specified via the ``disk`` element. per-process basis). This attribute is only valid when device is "lun". NB, ``rawio`` intends to confine the capability per-device, however, current QEMU implementation gives the domain process broader capability than that - (per-process basis, affects all the domain disks). To confine the - capability as much as possible for QEMU driver as this stage, ``sgio`` is - recommended, it's more secure than ``rawio``. :since:`Since 0.9.10` + (per-process basis, affects all the domain disks). :since:`Since 0.9.10` ``sgio`` If supported by the hypervisor and OS, indicates whether unprivileged SG_IO commands are filtered for the disk. Valid settings are "filtered" or "unfiltered" where the default is "filtered". Only available when the - ``device`` is 'lun'. :since:`Since 1.0.2` + ``device`` is 'lun'. The attribute exists :since:`Since 1.0.2`, although + currently it's no longer supported by any hypervisor. ``snapshot`` Indicates the default behavior of the disk during disk snapshots: ``internal`` requires a file format such as qcow2 that can store both @@ -4346,7 +4345,7 @@ or: ... <devices> - <hostdev mode='subsystem' type='scsi' sgio='filtered' rawio='yes'> + <hostdev mode='subsystem' type='scsi' rawio='yes'> <source> <adapter name='scsi_host0'/> <address bus='0' target='0' unit='0'/> @@ -4436,14 +4435,19 @@ or: ``display`` attribute to be set to ``on``. ``scsi`` For SCSI devices, user is responsible to make sure the device is not used - by host. If supported by the hypervisor and OS, the optional ``sgio`` ( - :since:`since 1.0.6` ) attribute indicates whether unprivileged SG_IO - commands are filtered for the disk. Valid settings are "filtered" or - "unfiltered", where the default is "filtered". The optional ``rawio`` ( - :since:`since 1.2.9` ) attribute indicates whether the lun needs the rawio - capability. Valid settings are "yes" or "no". See the rawio description - within the `Hard drives, floppy disks, CDROMs`_ section. If a disk lun in the domain - already has the rawio capability, then this setting not required. + by host. + + If supported by the hypervisor and OS, the optional ``sgio`` ( + :since:`since 1.0.6`, but currently no longer supported by any hypervisor + driver ) attribute indicates whether unprivileged SG_IO commands are + filtered for the disk. Valid settings are "filtered" or + "unfiltered", where the default is "filtered". + + The optional ``rawio`` (:since:`since 1.2.9` ) attribute indicates whether + the lun needs the rawio capability. Valid settings are "yes" or "no". + See the rawio description within the `Hard drives, floppy disks, CDROMs`_ + section. If a disk lun in the domain already has the rawio capability, + then this setting not required. ``scsi_host`` :since:`since 2.5.0` For SCSI devices, user is responsible to make sure the device is not used by host. This ``type`` passes all LUNs presented by -- 2.47.0

2 1

[PATCH] Revert "network: add rule to nftables backend that zeroes checksum of DHCP responses"
by Laine Stump 30 Oct '24

30 Oct '24

This reverts commit 42ab0148dd11727f7e3fd31dce4485469af290d5. This patch was supposed to fix the checksum of dhcp response packets by setting it to 0 (because having a non-0 but incorrect checksum was causing the packets to be droppe on FreeBSD guests). Early testing was positive, but after the patch was pushed upstream and more people could test it, it turned out that while it fixed the dhcp checksum problem for virtio-net interfaces on FreeBSD and OpenBSD, it also *broke* dhcp checksums for the e1000 emulated NIC on *all* guests (but not e1000e). So we're reverting this fix and looking for something more universal to be included in the next release. Signed-off-by: Laine Stump <laine(a)redhat.com> --- src/network/network_nftables.c | 69 ------------------- tests/networkxml2firewalldata/base.nftables | 14 ---- .../forward-dev-linux.nftables | 16 ----- .../isolated-linux.nftables | 16 ----- .../nat-default-linux.nftables | 16 ----- .../nat-ipv6-linux.nftables | 16 ----- .../nat-ipv6-masquerade-linux.nftables | 16 ----- .../nat-many-ips-linux.nftables | 16 ----- .../nat-port-range-ipv6-linux.nftables | 16 ----- .../nat-port-range-linux.nftables | 16 ----- .../nat-tftp-linux.nftables | 16 ----- .../route-default-linux.nftables | 16 ----- 12 files changed, 243 deletions(-) diff --git a/src/network/network_nftables.c b/src/network/network_nftables.c index 5523207269..f8b5ab665d 100644 --- a/src/network/network_nftables.c +++ b/src/network/network_nftables.c @@ -51,7 +51,6 @@ VIR_LOG_INIT("network.nftables"); #define VIR_NFTABLES_FWD_OUT_CHAIN "guest_output" #define VIR_NFTABLES_FWD_X_CHAIN "guest_cross" #define VIR_NFTABLES_NAT_POSTROUTE_CHAIN "guest_nat" -#define VIR_NFTABLES_MANGLE_POSTROUTE_CHAIN "postroute_mangle" /* we must avoid using the standard "filter" table as used by * iptables, as any subsequent attempts to use iptables commands will @@ -107,10 +106,6 @@ nftablesGlobalChain nftablesChains[] = { /* chains for NAT rules */ {NULL, VIR_NFTABLES_NAT_POSTROUTE_CHAIN, "{ type nat hook postrouting priority 100; policy accept; }"}, - - /* chain for "mangle" rules that modify packets (e.g. 0 out UDP checksums) */ - {NULL, VIR_NFTABLES_MANGLE_POSTROUTE_CHAIN, "{ type filter hook postrouting priority 0; policy accept; }"}, - }; @@ -649,44 +644,6 @@ nftablesAddDontMasquerade(virFirewall *fw, } -/** - * nftablesAddOutputFixUdpChecksum: - * - * Add a rule to @fw that will 0 out the checksum of udp packets - * output from @iface with destination port @port. - - * Zeroing the checksum of a UDP packet tells the receiving end "you - * don't need to validate the checksum", which is useful in cases - * where the host (sender) thinks that packet checksums will be - * computed elsewhere (and so leaves a partially computed checksum in - * the packet header) while the guest (receiver) thinks that the - * checksum has already been fully computed; in the meantime none of - * the code in between has actually finished computing the - * checksum. - * - * An example of this is DHCP response packets from host to - * guest. If the checksum of each of these packets isn't zeroed, then - * many guests (e.g. FreeBSD) will drop them with reason BAD CHECKSUM; - * if the packets arrive at those guests with a checksum of 0, they - * will happily accept the packet. - */ -static void -nftablesAddOutputFixUdpChecksum(virFirewall *fw, - const char *iface, - int port) -{ - g_autofree char *portstr = g_strdup_printf("%d", port); - - virFirewallAddCmd(fw, VIR_FIREWALL_LAYER_IPV4, - "insert", "rule", "ip", - VIR_NFTABLES_PRIVATE_TABLE, - VIR_NFTABLES_MANGLE_POSTROUTE_CHAIN, - "oif", iface, "udp", "dport", portstr, - "counter", "udp", "checksum", "set", "0", - NULL); -} - - static const char networkLocalMulticastIPv4[] = "224.0.0.0/24"; static const char networkLocalMulticastIPv6[] = "ff02::/16"; static const char networkLocalBroadcast[] = "255.255.255.255/32"; @@ -944,30 +901,6 @@ nftablesAddGeneralFirewallRules(virFirewall *fw, } -static void -nftablesAddChecksumFirewallRules(virFirewall *fw, - virNetworkDef *def) -{ - size_t i; - virNetworkIPDef *ipv4def; - - /* Look for the first IPv4 address that has dhcp or tftpboot - * defined. We support dhcp config on 1 IPv4 interface only. - */ - for (i = 0; (ipv4def = virNetworkDefGetIPByIndex(def, AF_INET, i)); i++) { - if (ipv4def->nranges || ipv4def->nhosts) - break; - } - - /* If we are doing local DHCP service on this network, add a rule - * that will fixup the checksum of DHCP response packets back to - * the guests. - */ - if (ipv4def) - nftablesAddOutputFixUdpChecksum(fw, def->bridge, 68); -} - - static int nftablesAddIPSpecificFirewallRules(virFirewall *fw, virNetworkDef *def, @@ -1019,8 +952,6 @@ nftablesAddFirewallRules(virNetworkDef *def, virFirewall **fwRemoval) return -1; } - nftablesAddChecksumFirewallRules(fw, def); - if (virFirewallApply(fw) < 0) return -1; diff --git a/tests/networkxml2firewalldata/base.nftables b/tests/networkxml2firewalldata/base.nftables index 6371fc12dd..a064318739 100644 --- a/tests/networkxml2firewalldata/base.nftables +++ b/tests/networkxml2firewalldata/base.nftables @@ -68,13 +68,6 @@ libvirt_network \ guest_nat \ '{ type nat hook postrouting priority 100; policy accept; }' nft \ -add \ -chain \ -ip \ -libvirt_network \ -postroute_mangle \ -'{ type filter hook postrouting priority 0; policy accept; }' -nft \ list \ table \ ip6 \ @@ -143,10 +136,3 @@ ip6 \ libvirt_network \ guest_nat \ '{ type nat hook postrouting priority 100; policy accept; }' -nft \ -add \ -chain \ -ip6 \ -libvirt_network \ -postroute_mangle \ -'{ type filter hook postrouting priority 0; policy accept; }' diff --git a/tests/networkxml2firewalldata/forward-dev-linux.nftables b/tests/networkxml2firewalldata/forward-dev-linux.nftables index 9dea1a88a4..8badb74beb 100644 --- a/tests/networkxml2firewalldata/forward-dev-linux.nftables +++ b/tests/networkxml2firewalldata/forward-dev-linux.nftables @@ -156,19 +156,3 @@ daddr \ 224.0.0.0/24 \ counter \ return -nft \ --ae insert \ -rule \ -ip \ -libvirt_network \ -postroute_mangle \ -oif \ -virbr0 \ -udp \ -dport \ -68 \ -counter \ -udp \ -checksum \ -set \ -0 diff --git a/tests/networkxml2firewalldata/isolated-linux.nftables b/tests/networkxml2firewalldata/isolated-linux.nftables index 67ee0a2bf5..d1b4dac178 100644 --- a/tests/networkxml2firewalldata/isolated-linux.nftables +++ b/tests/networkxml2firewalldata/isolated-linux.nftables @@ -62,19 +62,3 @@ oif \ virbr0 \ counter \ accept -nft \ --ae insert \ -rule \ -ip \ -libvirt_network \ -postroute_mangle \ -oif \ -virbr0 \ -udp \ -dport \ -68 \ -counter \ -udp \ -checksum \ -set \ -0 diff --git a/tests/networkxml2firewalldata/nat-default-linux.nftables b/tests/networkxml2firewalldata/nat-default-linux.nftables index 951a5a6d60..28508292f9 100644 --- a/tests/networkxml2firewalldata/nat-default-linux.nftables +++ b/tests/networkxml2firewalldata/nat-default-linux.nftables @@ -142,19 +142,3 @@ daddr \ 224.0.0.0/24 \ counter \ return -nft \ --ae insert \ -rule \ -ip \ -libvirt_network \ -postroute_mangle \ -oif \ -virbr0 \ -udp \ -dport \ -68 \ -counter \ -udp \ -checksum \ -set \ -0 diff --git a/tests/networkxml2firewalldata/nat-ipv6-linux.nftables b/tests/networkxml2firewalldata/nat-ipv6-linux.nftables index 617ed8b753..d8a9ba706d 100644 --- a/tests/networkxml2firewalldata/nat-ipv6-linux.nftables +++ b/tests/networkxml2firewalldata/nat-ipv6-linux.nftables @@ -200,19 +200,3 @@ oif \ virbr0 \ counter \ accept -nft \ --ae insert \ -rule \ -ip \ -libvirt_network \ -postroute_mangle \ -oif \ -virbr0 \ -udp \ -dport \ -68 \ -counter \ -udp \ -checksum \ -set \ -0 diff --git a/tests/networkxml2firewalldata/nat-ipv6-masquerade-linux.nftables b/tests/networkxml2firewalldata/nat-ipv6-masquerade-linux.nftables index a710d0e296..a7f09cda59 100644 --- a/tests/networkxml2firewalldata/nat-ipv6-masquerade-linux.nftables +++ b/tests/networkxml2firewalldata/nat-ipv6-masquerade-linux.nftables @@ -272,19 +272,3 @@ daddr \ ff02::/16 \ counter \ return -nft \ --ae insert \ -rule \ -ip \ -libvirt_network \ -postroute_mangle \ -oif \ -virbr0 \ -udp \ -dport \ -68 \ -counter \ -udp \ -checksum \ -set \ -0 diff --git a/tests/networkxml2firewalldata/nat-many-ips-linux.nftables b/tests/networkxml2firewalldata/nat-many-ips-linux.nftables index 0be5fb7e65..b826fe6134 100644 --- a/tests/networkxml2firewalldata/nat-many-ips-linux.nftables +++ b/tests/networkxml2firewalldata/nat-many-ips-linux.nftables @@ -366,19 +366,3 @@ daddr \ 224.0.0.0/24 \ counter \ return -nft \ --ae insert \ -rule \ -ip \ -libvirt_network \ -postroute_mangle \ -oif \ -virbr0 \ -udp \ -dport \ -68 \ -counter \ -udp \ -checksum \ -set \ -0 diff --git a/tests/networkxml2firewalldata/nat-port-range-ipv6-linux.nftables b/tests/networkxml2firewalldata/nat-port-range-ipv6-linux.nftables index 7574356855..ceaed6fa40 100644 --- a/tests/networkxml2firewalldata/nat-port-range-ipv6-linux.nftables +++ b/tests/networkxml2firewalldata/nat-port-range-ipv6-linux.nftables @@ -384,19 +384,3 @@ daddr \ ff02::/16 \ counter \ return -nft \ --ae insert \ -rule \ -ip \ -libvirt_network \ -postroute_mangle \ -oif \ -virbr0 \ -udp \ -dport \ -68 \ -counter \ -udp \ -checksum \ -set \ -0 diff --git a/tests/networkxml2firewalldata/nat-port-range-linux.nftables b/tests/networkxml2firewalldata/nat-port-range-linux.nftables index 127536e4db..1dc37a26ec 100644 --- a/tests/networkxml2firewalldata/nat-port-range-linux.nftables +++ b/tests/networkxml2firewalldata/nat-port-range-linux.nftables @@ -312,19 +312,3 @@ oif \ virbr0 \ counter \ accept -nft \ --ae insert \ -rule \ -ip \ -libvirt_network \ -postroute_mangle \ -oif \ -virbr0 \ -udp \ -dport \ -68 \ -counter \ -udp \ -checksum \ -set \ -0 diff --git a/tests/networkxml2firewalldata/nat-tftp-linux.nftables b/tests/networkxml2firewalldata/nat-tftp-linux.nftables index 951a5a6d60..28508292f9 100644 --- a/tests/networkxml2firewalldata/nat-tftp-linux.nftables +++ b/tests/networkxml2firewalldata/nat-tftp-linux.nftables @@ -142,19 +142,3 @@ daddr \ 224.0.0.0/24 \ counter \ return -nft \ --ae insert \ -rule \ -ip \ -libvirt_network \ -postroute_mangle \ -oif \ -virbr0 \ -udp \ -dport \ -68 \ -counter \ -udp \ -checksum \ -set \ -0 diff --git a/tests/networkxml2firewalldata/route-default-linux.nftables b/tests/networkxml2firewalldata/route-default-linux.nftables index be9c4f5439..282c9542a5 100644 --- a/tests/networkxml2firewalldata/route-default-linux.nftables +++ b/tests/networkxml2firewalldata/route-default-linux.nftables @@ -56,19 +56,3 @@ oif \ virbr0 \ counter \ accept -nft \ --ae insert \ -rule \ -ip \ -libvirt_network \ -postroute_mangle \ -oif \ -virbr0 \ -udp \ -dport \ -68 \ -counter \ -udp \ -checksum \ -set \ -0 -- 2.47.0

2 1

[PATCH 0/2] Cleanups of improper use of memory allocation APIs
by Peter Krempa 29 Oct '24

29 Oct '24

Peter Krempa (2): Replace improper use of g_malloc(0) with g_new0 virstring: Use 'g_new0' instead of improper use of 'g_malloc0_n' build-aux/syntax-check.mk | 4 ++-- src/util/virpcivpd.c | 6 +++--- src/util/virstring.c | 4 +--- tools/wireshark/src/packet-libvirt.c | 2 +- 4 files changed, 7 insertions(+), 9 deletions(-) -- 2.47.0

2 3

[PATCH] virJSONValueFromString: Prefix error message from 'json-c'
by Peter Krempa 25 Oct '24

25 Oct '24

The error message from 'json-c' was passed along without any libvirt string which makes it hard to find in the source and isn't exactly clear when present in logs: libvirtd[843]: internal error : invalid utf-8 string Prefix the message with 'failed to parse JSON'. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/util/virjson.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/util/virjson.c b/src/util/virjson.c index 42018a98b4..4a95e84f5b 100644 --- a/src/util/virjson.c +++ b/src/util/virjson.c @@ -1467,7 +1467,8 @@ virJSONValueFromString(const char *jsonstring) jerr = json_tokener_get_error(tok); if (jerr != json_tokener_success) { virReportError(VIR_ERR_INTERNAL_ERROR, - "%s", json_tokener_error_desc(jerr)); + _("failed to parse JSON: %1$s"), + json_tokener_error_desc(jerr)); goto cleanup; } ret = virJSONValueFromJsonC(jobj); -- 2.47.0

2 1