- dev - passt

[PATCH v10 0/9] Use true MAC address of LAN local remote hosts
by Jon Maloy 27 Sep '25

27 Sep '25

Bug #120 asks us to use the true MAC addresses of LAN local remote hosts, since some programs need this information. These commits introduces this for ARP, NDP, UDP, TCP and ICMP. --- v3: Updated according to feedback from Stefano and David: - Made the ARP/NDP lookup call filter out the requested address by itself, qualified by the index if the template interface - Moved the flow specific MAC address from struct flowside to struct flow_common. v4: - Updated according to feedback from David and Stefan - Added a cache table for ARP/NDP table contents v5: - Updated according to feedback from David and Stefan - Added cache table entries to FIFO/LRU queue - New criteria for when to consult ARP/NDP v6: - Simplified and merged mac cache table commits - Other changes after feedback from David. v7: - Fixes in patch #2 based on feedback from David and Stefano. v8: - Redesigned netlink and cache table part to be based on a subscription model. v8: - Small fix to patch #2 so that we cover the case when a MAC addess for a host has changed. - Added a commit where we send a gratuitous ARP/ unsolicitated NA to the guest when a new host is added to the neighbour cache table. c10: - Some fixes after feedback from David Gibson - Reordered: Moved patch #9 to position #3. - Added synchronization step between ARP/NDP table contents and the neigbour table at initialization. This reduces the number of "false" ARP/NDP replies drastically, but not completly. - (Next step could be to scan over the flow table and update affeced entries when we receive a MAC address update.) Jon Maloy (8): netlink: add subsciption on changes in NDP/ARP table fwd: Add cache table for ARP/NDP contents arp/ndp: respond with true MAC address of LAN local remote hosts flow: add MAC address of LAN local remote hosts to flow udp: forward external source MAC address through tap interface tcp: forward external source MAC address through tap interface tap: change signature of function tap_push_l2h() icmp: let icmp use mac address from flowside structure arp.c | 9 ++- conf.c | 1 + epoll_type.h | 2 + flow.c | 2 + flow.h | 2 + fwd.c | 167 +++++++++++++++++++++++++++++++++++++++++++++++-- fwd.h | 9 +++ icmp.c | 8 ++- inany.c | 1 + ndp.c | 10 ++- netlink.c | 119 +++++++++++++++++++++++++++++++++++ netlink.h | 4 ++ passt.c | 17 +++-- passt.h | 3 +- pasta.c | 2 +- tap.c | 24 ++++--- tap.h | 7 ++- tcp.c | 18 ++++-- tcp.h | 2 +- tcp_buf.c | 37 +++++------ tcp_internal.h | 4 +- tcp_vu.c | 5 +- udp.c | 57 ++++++++++------- udp.h | 2 +- 24 files changed, 429 insertions(+), 83 deletions(-) -- 2.50.1

1 9

[PATCH] test: Update mbuto profile to fix the symlink of /bin
by Yumei Huang 26 Sep '25

26 Sep '25

When running test 'migrate/rampstream_out' on fedora, test fails with error like this: guest_1$ socat -u EXEC:"rampstream send 6000000" TCP4:192.0.2.1:10006 2025/09/24 04:06:12 socat[405] E execvp("rampstream", "rampstream", "send", "6000000", ...): No such file or directory It's because on fedora, /bin is not in the PATH, and some binaries are under /usr/bin. mbuto will find the binaries on the host and put them into the guest under same directories. As a result, /usr/bin in mbuto guest are not empty, causing creating /usr/bin symlink failed. Thus, the script 'rampstream' under /bin is not found during testing. This patch fixes the issue and creates the symlink for consistency with /sbin. Link: https://bugs.passt.top/show_bug.cgi?id=151 Suggested-by: David Gibson <david(a)gibson.dropbear.id.au> Signed-off-by: Yumei Huang <yuhuang(a)redhat.com> --- test/passt.mbuto | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/test/passt.mbuto b/test/passt.mbuto index 176cf3f..231b9c9 100755 --- a/test/passt.mbuto +++ b/test/passt.mbuto @@ -64,7 +64,9 @@ set >> \$LOG exit 0 EOF chmod 755 /sbin/dhclient-script - ln -s /bin /usr/bin + mv /bin/* /usr/bin || : + rm -rf /bin + ln -s /usr/bin /bin ln -s /run /var/run :> /etc/fstab -- 2.47.0

2 1

[PATCH v2] test: fix 'make assets' failure as root
by Yumei Huang 26 Sep '25

26 Sep '25

Running `make assets` under `test` as root fails with a "Permission denied" error when `prepare-distro-img.sh` invokes `virt-edit` and `guestfish`. This is due to a known bug in libvirt. Work around the issue by switching to the direct backend. Signed-off-by: Yumei Huang <yuhuang(a)redhat.com> --- test/prepare-distro-img.sh | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/test/prepare-distro-img.sh b/test/prepare-distro-img.sh index 0d967c9..be2386e 100755 --- a/test/prepare-distro-img.sh +++ b/test/prepare-distro-img.sh @@ -3,6 +3,10 @@ IMG="$1" PASST_FILES="$(echo ../*.c ../*.h ../*.sh ../*.1 ../Makefile ../README.md)" +# This is just a workaround for Fedora and related distributions. +# Once it gets fixed, we can drop this. +export LIBGUESTFS_BACKEND=direct + virt-edit -a $IMG /lib/systemd/system/serial-getty@.service -e 's/ExecStart=.*/ExecStart=\/sbin\/agetty --autologin root -8 --keep-baud 115200,38400,9600 %I $TERM/g' guestfish --rw -a $IMG -i <<EOF -- 2.47.0

3 2

[PATCH] test: fix 'make assets' failure as root
by Yumei Huang 26 Sep '25

26 Sep '25

Running `make assets` under `test` as root fails with a "Permission denied" error when `prepare-distro-img.sh` invokes `virt-edit` and `guestfish`. This is due to a known bug in libvirt. Work around the issue by switching to the direct backend. Signed-off-by: Yumei Huang <yuhuang(a)redhat.com> --- test/prepare-distro-img.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/test/prepare-distro-img.sh b/test/prepare-distro-img.sh index 0d967c9..423eea7 100755 --- a/test/prepare-distro-img.sh +++ b/test/prepare-distro-img.sh @@ -3,6 +3,8 @@ IMG="$1" PASST_FILES="$(echo ../*.c ../*.h ../*.sh ../*.1 ../Makefile ../README.md)" +export LIBGUESTFS_BACKEND=direct + virt-edit -a $IMG /lib/systemd/system/serial-getty@.service -e 's/ExecStart=.*/ExecStart=\/sbin\/agetty --autologin root -8 --keep-baud 115200,38400,9600 %I $TERM/g' guestfish --rw -a $IMG -i <<EOF -- 2.47.0

4 6

[PATCH v2] tap: Drop frames if no client connected
by Yumei Huang 25 Sep '25

25 Sep '25

If no client is attached, discard outgoing frames and report them as sent. Without this we will get an EBADF in either writev() (pasta) or sendmsg() (passt). That's basically harmless, but a bit ugly. Explicitly catching this case results in behaviour that's probably a bit clearer to debug if we hit it. There are several different approaches we can take here. Here's some reasoning as David explained: * Don't listen() until the tap connection is ready - It's not clear that the host rejecting the connection is better than the host accepting, then the connection stalling until the guest is ready. - Would require substantial rework because we currently listen() as we parse the command line and don't store the information we'd need to do it later. * Don't accept() until the tap connection is ready - To the peer, will behave basically the same as this patch - the host will complete the TCP handshake, then the connection will stall until the guest is ready. - More work to implement, because essentially every sock-side handler has to check fd_tap and abort early * Drop packets in tap_send_frames(), but return 0 - To the peer, would behave basically the same - Would make the TCP code do a bunch of busy work attempting to resend, probably to no avail - Handling of errors returned by tap_send_frames() is on the basis that it's probably a transient fault (buffer full) and we want to resend very soon. That approach doesn't make sense for a missing guest. Suggested-by: David Gibson <david(a)gibson.dropbear.id.au> Signed-off-by: Yumei Huang <yuhuang(a)redhat.com> --- tap.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tap.c b/tap.c index 7ba6399..2e371b3 100644 --- a/tap.c +++ b/tap.c @@ -507,13 +507,16 @@ static size_t tap_send_frames_passt(const struct ctx *c, * @iov must have total length @bufs_per_frame * @nframes, with each set of * @bufs_per_frame contiguous buffers representing a single frame. * - * Return: number of frames actually sent + * Return: number of frames actually sent, or accounted as sent */ size_t tap_send_frames(const struct ctx *c, const struct iovec *iov, size_t bufs_per_frame, size_t nframes) { size_t m; + if (c->fd_tap == -1) + return nframes; + if (!nframes) return 0; -- 2.47.0

3 2

[PATCH] test: Update README.md
by Yumei Huang 25 Sep '25

25 Sep '25

Signed-off-by: Yumei Huang <yuhuang(a)redhat.com> --- test/README.md | 31 +++++++++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-) diff --git a/test/README.md b/test/README.md index 91ca603..e3e9d37 100644 --- a/test/README.md +++ b/test/README.md @@ -32,7 +32,7 @@ Example for Debian, and possibly most Debian-based distributions: git go iperf3 isc-dhcp-common jq libgpgme-dev libseccomp-dev linux-cpupower lm-sensors lz4 netavark netcat-openbsd psmisc qemu-efi-aarch64 qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86 - qemu-system-x86 sipcalc socat strace tmux uidmap valgrind + sipcalc socat strace tmux uidmap valgrind NOTE: the tests need a qemu version >= 7.2, or one that contains commit 13c6be96618c ("net: stream: add unix socket"): this change introduces support @@ -81,7 +81,12 @@ The following additional packages are commonly needed: ## Regular test -Just issue: +Before running the tests, you need to prepare the required assets: + + cd test + make assets + +Then issue: ./run @@ -91,6 +96,28 @@ variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing PCAP=1 TRACE=1 ./run +**Note:** + +* It's recommended to run the commands as a non-root user. + Due to [Bug 967509](https://bugzilla.redhat.com/show_bug.cgi?id=967509), + if you switch users with `su` or `sudo`, the directory `/run/user/ID` may + not be created. In that case, `XDG_RUNTIME_DIR` will incorrectly point to + `/run/user/0` instead of `/run/user/ID`, which can cause error. + + **Workaround:** Log out and log back in as the intended user to ensure the + correct runtime directory is set up. + +* SELinux may prevent the tests from running correctly. To avoid this, + temporarily disable it by running: + + setenforce 0 + +* Some tests require a QEMU build that includes the following commits: + + 60f543ad917f ("virtio-net: vhost-user: Implement internal migration") + 3f65357313e0 ("vhost: Add stubs for the migration state transfer + interface") + ## Running selected tests Rudimentary support to run a list of selected tests, without support for -- 2.47.0

5 21

[PATCH] tap: Drop frames if no client connected
by Yumei Huang 25 Sep '25

25 Sep '25

If no client is attached, discard outgoing frames and report them as sent. This mimics the behavior of a physical host with its network cable unplugged. Suggested-by: David Gibson <david(a)gibson.dropbear.id.au> Signed-off-by: Yumei Huang <yuhuang(a)redhat.com> --- tap.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tap.c b/tap.c index 7ba6399..e01219d 100644 --- a/tap.c +++ b/tap.c @@ -507,13 +507,17 @@ static size_t tap_send_frames_passt(const struct ctx *c, * @iov must have total length @bufs_per_frame * @nframes, with each set of * @bufs_per_frame contiguous buffers representing a single frame. * - * Return: number of frames actually sent + * Return: number of frames actually sent, or accounted as sent */ size_t tap_send_frames(const struct ctx *c, const struct iovec *iov, size_t bufs_per_frame, size_t nframes) { size_t m; + if (c->fd_tap == -1) + /* If no client connected, account the frames have been sent */ + return nframes; + if (!nframes) return 0; -- 2.47.0

3 18

Re: [PATCH] test: Update README.md
by Stefano Brivio 24 Sep '25

24 Sep '25

On Wed, 24 Sep 2025 12:20:03 +0100 Daniel P. Berrangé <berrange(a)redhat.com> wrote: > On Wed, Sep 24, 2025 at 01:05:53PM +0200, Stefano Brivio wrote: > > On Wed, 24 Sep 2025 11:31:31 +0100 > > "Richard W.M. Jones" <rjones(a)redhat.com> wrote: > > > > > On Wed, Sep 24, 2025 at 11:09:09AM +0200, Stefano Brivio wrote: > > > > And now that you say that, I just realised that it would be as simple > > > > as: > > > > > > > > https://libguestfs.org/guestfs-faq.1.html#permission-denied-when-running-li… > > > > > > > > LIBGUESTFS_BACKEND=direct virt-edit... > > > > > > While that will indeed work, we're trying to discourage people from > > > doing that, since it removes the other good things that libvirt does, > > > such as setting up SELinux. > > > > Oh, I see. I guess it makes sense, with a number of caveats: > > > > 1. libvirt's SELinux policy doesn't seem to be really maintainable / > > long-term sustainable to me, especially because it's still part of > > fedora-selinux > > Well it isn't ideal that Fedora policy is largely centralized, but > it has been maintained it since 2007, so claiming it is not long > term sustainable is just FUD. I'd rather call it observation. We're just piling up workarounds because merge requests are not really evaluated or accepted, for example https://github.com/fedora-selinux/selinux-policy/pull/1613. Your own comment to it: https://github.com/fedora-selinux/selinux-policy/pull/1613#issuecomment-146… perfectly explains one of the biggest maintainability concerns I have, because not being able to use interfaces as designed leads to issues such as: https://github.com/fedora-selinux/selinux-policy/issues/2579 for which, again, I could propose a simple change, but I don't exactly have confidence that it will be considered. That leads in turn to more workarounds, say: https://passt.top/passt/commit/?id=87471731e6bb0b5df3a50277527caf3381b45ee4 https://passt.top/passt/commit/?id=98d474c8950e9cc5715d5686614fb0f504377303 I don't understand how the fact that it's been like that since 2007 would suggest a positive or negative correlation to maintainability. Things keeps breaking and I keep adding more workarounds, not fixes. You can go ahead and blame me for that, but I was talking about how *I* perceive maintainability. Again: > 1. libvirt's SELinux policy doesn't seem to be really maintainable / > long-term sustainable to me ^^ ...we probably have different concepts of it. That doesn't make it FUD. > > 2. it adds a rather artificial dependency on libvirt, so in the end > > you're running more things, and more complicated ones, even if it's > > not needed > > Libvirt provides a stable interface to interacting with QEMU > over decades. QEMU's own interface is only guaranteed stable > over 2 releases. As QEMU changes its interface and/or best > practice configuration approach, libvirt adapts to this so > every app doesn't have to repeat this work. It depends on the use case. For the use case at hand, we would be absolutely fine with things breaking every six months, or even more frequently. > > 3. the profile is still much looser than what a libguestfs specific > > profile could be, see for example the AppArmor policy I introduced > > at: > > > > https://salsa.debian.org/libvirt-team/guestfs-tools/-/commit/e638b1bcb8a662… > > > > which, despite being rather loose, is still arguably much stricter > > than this beast (and related add-ons): > > > > https://gitlab.com/libvirt/libvirt/-/blob/master/src/security/apparmor/usr.… > > > > and I think a strict subset of it, as well. > > This is the policy for the libvirt daemon, which is separate from the > policy that the QEMU guest runs under - the latter is constrained to > limit access to resources configured for the guest VM. > > The libvirt daemon policy needs to be loose by default, since users > want libvirt to be able to access a wide range of files and resources. > This same need applies to guestfish - it needs to access arbitrarily > specified disk images, so would need a very loose policy. About disk images, of course, that's what I added for libguestfs: /** mrwlk and that's the same in libvirt's AppArmor policy. The set of permitted capabilities is very different, though, and libguestfs doesn't of course need all those helpers or, say, the ability to mount /dev, which, with AppArmor, can't be qualified / limited much further than that. > Only the > spawned QEMU could be confined strictly, and that would be equiv to > what is already done with libvirt's policy for QEMU. ...see links above? Those are not equivalent. -- Stefano

1 0

[PATCH v8 0/8] Use true MAC address of LAN local remote hosts
by Jon Maloy 22 Sep '25

22 Sep '25

Bug #120 asks us to use the true MAC addresses of LAN local remote hosts, since some programs need this information. These commits introduces this for ARP, NDP, UDP, TCP and ICMP. --- v3: Updated according to feedback from Stefano and David: - Made the ARP/NDP lookup call filter out the requested address by itself, qualified by the index if the template interface - Moved the flow specific MAC address from struct flowside to struct flow_common. v4: - Updated according to feedback from David and Stefan - Added a cache table for ARP/NDP table contents v5: - Updated according to feedback from David and Stefan - Added cache table entries to FIFO/LRU queue - New criteria for when to consult ARP/NDP v6: - Simplified and merged mac cache table commits - Other changes after feedback from David. v7: - Fixes in patch #2 based on feedback from David and Stefano. v8: - Redesigned netlink and cache table part to be based on a subscription model. Jon Maloy (8): netlink: add subsciption on changes in NDP/ARP table fwd: Add cache table for ARP/NDP contents arp/ndp: respond with true MAC address of LAN local remote hosts flow: add MAC address of LAN local remote hosts to flow udp: forward external source MAC address through tap interface tcp: forward external source MAC address through tap interface tap: change signature of function tap_push_l2h() icmp: let icmp use mac address from flowside structure arp.c | 9 ++- conf.c | 1 + epoll_type.h | 2 + flow.c | 2 + flow.h | 2 + fwd.c | 167 +++++++++++++++++++++++++++++++++++++++++++++++-- fwd.h | 9 +++ icmp.c | 8 ++- inany.c | 1 + ndp.c | 10 ++- netlink.c | 119 +++++++++++++++++++++++++++++++++++ netlink.h | 4 ++ passt.c | 17 +++-- passt.h | 3 +- pasta.c | 2 +- tap.c | 24 ++++--- tap.h | 7 ++- tcp.c | 18 ++++-- tcp.h | 2 +- tcp_buf.c | 37 +++++------ tcp_internal.h | 4 +- tcp_vu.c | 5 +- udp.c | 57 ++++++++++------- udp.h | 2 +- 24 files changed, 429 insertions(+), 83 deletions(-) -- 2.50.1

1 8

Re: [PATCH 1/2] selinux: add container_var_run_t type transition
by Stefano Brivio 20 Sep '25

20 Sep '25

On Fri, 19 Sep 2025 11:22:20 -0400 Lokesh Mandvekar <lmandvek(a)redhat.com> wrote: > We now have pasta tests in place for container-selinux upstream > https://github.com/containers/container-selinux/pull/409 . > So, any future potential conflicts should be caught pre-merge. Thanks, that was quick! I'll keep you all posted once we have a release with the updated policy including container_var_run_t. -- Stefano

1 1