On Thursday, January 30th, 2025 at 12:33 AM, Stefano Brivio <sbrivio(a)redhat.com> wrote:On Wed, 29 Jan 2025 18:10:36 +0000 Prafulla Giri prafulla.giri(a)protonmail.com wrote:I didn't have auditd installed on Debian and installed it, and running everything with the default auditd config (with my Apparmor disabled for passt, as mentioned previously) does not result in anything. Do I have to configure auditd manually? Any pointers on that, please? On Fedora 41, which seems to have auditd preconfigured, there aren't any significant reports about passt.Hello, On Wednesday, January 29th, 2025 at 3:26 PM, Stefano Brivio sbrivio(a)redhat.com wrote::)Hi, On Wed, 29 Jan 2025 09:14:12 +0000 Prafulla Giri prafulla.giri(a)protonmail.com wrote:I'm glad to have bumped into you. Because of the email domain, I thought you weren't the Debian maintainer. Silly me.Esteemed maintainer, First and foremost, thank you very much for your hard work: passt is awesome and allows one to run more useful user-space VM-s. I have encountered 2 particular issues with the usage of passt with Debian, and wanted to bring them to your attention as I think you are probably the best person to deal with this. I do plan on sending a report to the Debian team afterwards. For reference, I tested these on Debian Testing Daily Image dated 28 January 2025, with updates, and the version of passt available with it is passt 0.0~git20250121.4f2c8e7-1 - Passt's default Apparmor config needs to allow writes to $XDG_RUNTIME_DIR (which is at /run/user/$UID). Currently it doesn't. Virt-manager, at least, tries to create the necessary sockets in the directory but apparmor prevents that from happening (and the error message Virt-Manager gives isn't helpful either: the first time around I falsely believed it was a segfault or similar issue). I managed to get passt working past this flaw (pun intended) by manually disabling apparmor for the binary. Passt works just fine in Fedora 41 as it doesn't use Apparmor but uses SELinux, and thus the configs don't affect it.Thanks for reporting this! I'm the maintainer of the Debian package, by the way. Cc'ing Andrea, who is a maintainer of the libvirt package for Debian and surely more knowledgeable about this.One thing that might help meanwhile is if you have a look at /var/log/audit/audit.log after the failure occurs. Look for 'passt' there. There should be a message logging a denied access to some file: what does it say?Note that virt-manager uses passt through libvirt (I think that's only possibility) and this should actually be allowed in libvirt's AppArmor policy, in the sub-profile for passt: https://gitlab.com/libvirt/libvirt/-/blob/0264a7704ada52f686cafe8f6402d5b60… the rationale is that passt itself doesn't know which directory libvirt will pick for its socket and PID files, so libvirt's policy has to specify that. So I think you should file an issue for the libvirt package in this case, unless Andrea has some pointers.I will wait for the maintainers input on this one.Here are the outputs: $ passt -f -d # on Debian Testing/Trixie 0.0016: No interfaces with usable IPv6 routes 0.0017: Failed to detect external interface for IPv6 0.0028: UNIX domain socket bound at /tmp/passt_1.socket 0.0029: Template interface: enp1s0 (IPv4) 0.0029: MAC: 0.0029: host: 9a:55:9a:55:9a:55 0.0029: NAT to host 127.0.0.1: 192.168.100.1 0.0029: DHCP: 0.0029: assign: 192.168.100.157 0.0029: mask: 255.255.255.0 0.0029: router: 192.168.100.1 0.0029: DNS: 0.0029: 192.168.100.1 0.0029: DNS search list: 0.0029: . 0.0056: You can now start qemu (>= 7.2, with commit 13c6be96618c): 0.0056: kvm ... -device virtio-net-pci,netdev=s -netdev stream,id=s,server=off,addr.type=unix,addr.path=/tmp/passt_1.socket 0.0057: or qrap, for earlier qemu versions: 0.0057: ./qrap 5 kvm ... -net socket,fd=5 -net nic,model=virtio 0.0067: SO_PEEK_OFF supported 0.0067: TCP_INFO tcpi_snd_wnd field supported 0.0067: TCP_INFO tcpi_bytes_acked field supported 0.0067: TCP_INFO tcpi_min_rtt field supported $ passt -f -d 0.0022: UNIX domain socket bound at /tmp/passt_1.socket 0.0022: Template interface: wlp0s20f3 (IPv4) 0.0022: MAC: 0.0022: host: 9a:55:9a:55:9a:55 0.0022: NAT to host 127.0.0.1: 192.168.100.1 0.0023: DHCP: 0.0023: assign: 192.168.100.157 0.0023: mask: 255.255.255.0 0.0023: router: 192.168.100.1 0.0023: DNS: 0.0023: 192.168.100.1 0.0023: DNS search list: 0.0023: . 0.0047: You can now start qemu (>= 7.2, with commit 13c6be96618c): 0.0047: kvm ... -device virtio-net-pci,netdev=s -netdev stream,id=s,server=off,addr.type=unix,addr.path=/tmp/passt_1.socket 0.0047: or qrap, for earlier qemu versions: 0.0047: ./qrap 5 kvm ... -net socket,fd=5 -net nic,model=virtio 0.0055: SO_PEEK_OFF supported 0.0055: TCP_INFO tcpi_snd_wnd field supported 0.0055: TCP_INFO tcpi_bytes_acked field supported 0.0055: TCP_INFO tcpi_min_rtt field supportedOkay, nothing unexpected so far. Could you also please compare the output of 'passt -f -d' between the two cases? Just terminate it with ^C once you have the output.Certainly! I'm sorry I didn't do this earlier. I'd checked on this: there is no difference between the command that runs passt on Fedora 41 or Debian Trixie. This is the command on Fedora 41: passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/4-dragora-net0.socket --pid /run/user/1000/libvirt/qemu/run/passt/4-dragora-net0-passt.pid and this is the command on Debian Trixie: passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/1-vm1-net0.socket --pid /run/user/1000/libvirt/qemu/run/passt/1-vm1-net0-passt.pid- This second issue is perhaps a bit more Debian-specific, but I am going to mention it so that you might drop some hints for the Debian maintainers to debug this: Once Apparmor is disabled and a VM is configured to work with passt, DNS resolution doesn't work in the VM (IP Addresses work just fine) i.e. ping fsf.org doesn't work but `ping 209.51.188.174` does. The hypervisor details follow: $ virsh version # on Debian Testing a.k.a. 'Trixie' Compiled against library: libvirt 11.0.0 Using library: libvirt 11.0.0 Using API: QEMU 11.0.0Running hypervisor: QEMU 9.2.0 This, again, isn't an issue with Fedora 41, where everything just works. The hypervisor details for Fedora 41 are: $ virsh version # on Fedora 41 Compiled against library: libvirt 10.6.0 Using library: libvirt 10.6.0 Using API: QEMU 10.6.0 Running hypervisor: QEMU 9.1.2Oops. Can you share the command line of passt as run by libvirt (say, 'ps aux|grep passt') for this case? passt has some basic DNS forwarding capabilities, which are configured depending on the host's resolver configuration.How are resolvers configured on the two hosts? What does /etc/resolv.conf say?$ cat /etc/resolv.conf # On Fedora 41 # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8). [...] nameserver 127.0.0.53 options edns0 trust-ad search . $ cat /etc/resolv.conf # On Debian Trixie # This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8). [...] nameserver 192.168.100.1 search . $ cat /etc/resolv.conf # On a Debian 11 OS # Generated by NetworkManager nameserver 192.168.100.1 Also the output of `resolvectl status` for good measure: # On Fedora 41 Global Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Link 2 (wlp0s20f3) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.100.1 DNS Servers: 192.168.100.1 # On Debian Trixie Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: uplink Link 2 (enp1s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 192.168.100.1 Default Route: yesIf nothing is visible from there, next check: 'virsh edit vm1' on Debian and add a log file in the XML, that is, replace this line: <backend type='passt'/> with: <backend type='passt' logFile='/tmp/passt.log'/> and then share the log.The log from Debian Trixie host for VM1: passt 0.0~git20250121.4f2c8e7-1: /usr/bin/passt.avx2 (6428) 0.0017: info: No interfaces with usable IPv6 routes 0.0029: info: UNIX domain socket bound at /run/user/1000/libvirt/qemu/run/passt/2-vm1-net0.socket 0.0030: info: Template interface: enp1s0 (IPv4) 0.0030: info: MAC: 0.0030: info: host: 9a:55:9a:55:9a:55 0.0030: info: NAT to host 127.0.0.1: 192.168.100.1 0.0030: info: DHCP: 0.0031: info: assign: 192.168.100.157 0.0031: info: mask: 255.255.255.0 0.0031: info: router: 192.168.100.1 0.0031: info: DNS: 0.0031: info: 192.168.100.1 0.0031: info: DNS search list: 0.0031: info: . 0.0066: info: You can now start qemu (>= 7.2, with commit 13c6be96618c): 0.0066: info: kvm ... -device virtio-net-pci,netdev=s -netdev stream,id=s,server=off,addr.type=unix,addr.path=/run/user/1000/libvirt/qemu/run/passt/2-vm1-net0.socket 0.0066: info: or qrap, for earlier qemu versions: 0.0066: info: ./qrap 5 kvm ... -net socket,fd=5 -net nic,model=virtio 0.0617: info: accepted connection from PID 0 38.6257: info: DHCP: offer to discover 38.6257: info: from 52:54:00:a0:e1:7c 38.6471: info: DHCP: ack to request 38.6471: info: from 52:54:00:a0:e1:7c 451.4989: info: Client connection closed, exiting The log from Fedora 41: passt 0^20250121.g4f2c8e7-2.fc41.x86_64: /usr/bin/passt.avx2 (3138) 0.0017: info: UNIX domain socket bound at /run/user/1000/libvirt/qemu/run/passt/3-debian-trixie-net0.socket 0.0018: info: Template interface: wlp0s20f3 (IPv4) 0.0018: info: MAC: 0.0018: info: host: 9a:55:9a:55:9a:55 0.0018: info: NAT to host 127.0.0.1: 192.168.100.1 0.0018: info: DHCP: 0.0018: info: assign: 192.168.100.157 0.0018: info: mask: 255.255.255.0 0.0018: info: router: 192.168.100.1 0.0018: info: DNS: 0.0018: info: 192.168.100.1 0.0018: info: DNS search list: 0.0018: info: . 0.0043: info: You can now start qemu (>= 7.2, with commit 13c6be96618c): 0.0043: info: kvm ... -device virtio-net-pci,netdev=s -netdev stream,id=s,server=off,addr.type=unix,addr.path=/run/user/1000/libvirt/qemu/run/passt/3-debian-trixie-net0.socket 0.0043: info: or qrap, for earlier qemu versions: 0.0043: info: ./qrap 5 kvm ... -net socket,fd=5 -net nic,model=virtio 0.0591: info: accepted connection from PID 0 10.7894: info: DHCP: ack to discover (Rapid Commit) 10.7894: info: from 52:54:00:8f:e7:c3 99.6704: info: Client connection closed, exiting-- Stefano