- dev - passt

[PATCH] RFC: Don't override system's default ping_group_range for pasta
by David Gibson 08 Sep '26

08 Sep '26

When spawning a command, pasta sets the net.ipv4.ping_group_range sysctl to 0 0, meaning only group 0 can use ping sockets within the namespace. Since group 0 is the only one we map in the userns, that's equivalent to anyone being able to use ping sockets. Although the kernel default for this is 1 0 (nobody can use ping sockets), common distros - at least ones using systemd or even just systemd-udevd - appear to set it to "0 2147483647" meaning effectively anyone can use ping sockets. There's no obvious reason that we need to override the system's default behaviour here. The override was introduced in 32d07f5e5 ("passt, pasta: Completely avoid dynamic memory allocation") as part of a large chunk which kind of looks like it was meant to be in another patch, so the git history isn't particularly informative. Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- pasta.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/pasta.c b/pasta.c index 5aa56b78..4248b508 100644 --- a/pasta.c +++ b/pasta.c @@ -198,9 +198,6 @@ static int pasta_spawn_cmd(void *arg) if (mount("", "/proc", "proc", 0, NULL)) warn_perror("Couldn't mount /proc"); - if (write_file("/proc/sys/net/ipv4/ping_group_range", "0 0")) - warn("Cannot set ping_group_range, ICMP requests might fail"); - a = (const struct pasta_spawn_cmd_arg *)arg; conf_hostname_len = strlen(a->c->hostname); -- 2.55.0

2 2

[PATCH] pasta: Add --no-pidns to keep spawned command in caller's PID namespace
by Christian Korneck 08 Sep '26

08 Sep '26

This is to allow running pasta inside a container without unmasking /proc for the whole container (Docker's --security-opt systempaths=unconfined, Podman's --security-opt unmask=ALL), which is undesirable as it exposes /proc/sysrq-trigger and other masked paths. In spawn mode, pasta clones the command with CLONE_NEWPID and mounts a new procfs instance on /proc, so that it matches the new PID namespace. Mounting procfs in a new user namespace requires a fully visible, unobstructed procfs. Container runtimes deliberately obstruct /proc (Docker, for example, masks /proc/kcore and friends and mounts /proc/sys read-only), so the mount is refused: Couldn't mount /proc: Operation not permitted We only warn and continue, leaving the command in a new PID namespace while the visible /proc still numbers processes in the outer one. Anything resolving its own PID through /proc then fails, for example bubblewrap: bwrap: open /proc/22/ns/ns failed: No such file or directory Add a --no-pidns option: skip CLONE_NEWPID for the spawned command and don't mount /proc, which is then not needed. User, network, mount, UTS and IPC namespaces, --config-net and port forwarding are unaffected. The option is rejected together with PID or --netns, as it only makes sense when we spawn the command ourselves. Add a test checking that, by default, the command runs in a new PID namespace, and that --no-pidns keeps it in the caller's one. Signed-off-by: Christian Korneck <christian(a)korneck.de> --- conf.c | 11 +++++++++++ passt.1 | 12 ++++++++++++ passt.h | 2 ++ pasta.c | 18 +++++++++++------- test/pasta_options/no_pidns | 25 +++++++++++++++++++++++++ test/run | 1 + 6 files changed, 62 insertions(+), 7 deletions(-) create mode 100644 test/pasta_options/no_pidns diff --git a/conf.c b/conf.c index faf2681..16b2f40 100644 --- a/conf.c +++ b/conf.c @@ -742,6 +742,7 @@ pasta_opts: " implied if PATH or NAME are given without --userns\n" " --no-netns-quit Don't quit if filesystem-bound target\n" " network namespace is deleted\n" + " --no-pidns Don't spawn command in a new PID namespace\n" " --config-net Configure tap interface in namespace\n" " --no-copy-routes DEPRECATED:\n" " Don't copy all routes to namespace\n" @@ -1348,6 +1349,7 @@ void conf(struct ctx *c, int argc, char **argv) {"stats", required_argument, NULL, 31 }, {"conf-path", required_argument, NULL, 'c' }, {"chroot-fallback", no_argument, NULL, 32 }, + {"no-pidns", no_argument, NULL, 33 }, { 0 }, }; const char *optstring = "+dqfel:hs:c:F:I:p:P:m:a:n:M:g:i:o:D:S:H:461t:u:T:U:"; @@ -1589,6 +1591,12 @@ void conf(struct ctx *c, int argc, char **argv) case 32: c->chroot_fallback = true; break; + case 33: + if (c->mode != MODE_PASTA) + die("--no-pidns is for pasta mode only"); + + c->no_pidns = true; + break; case 'd': c->debug = 1; c->quiet = 0; @@ -1948,6 +1956,9 @@ void conf(struct ctx *c, int argc, char **argv) else if (optind != argc) die("Extra non-option argument: %s", argv[optind]); + if (c->no_pidns && *netns) + die("--no-pidns is incompatible with PID or --netns"); + conf_open_files(c); /* Before any possible setuid() / setgid() */ isolate_user(c, uid, gid, !netns_only, userns); diff --git a/passt.1 b/passt.1 index 53e072a..0b780fe 100644 --- a/passt.1 +++ b/passt.1 @@ -704,6 +704,18 @@ is bound to the filesystem, and the given path is deleted, or if the target network namespace is represented by a procfs entry, and that entry is deleted, representing the fact that a process with the given PID terminated. +.TP +.BR \-\-no-pidns +Don't create a new PID namespace for the spawned command or shell: keep it in +the PID namespace \fBpasta\fR itself runs in, and don't mount a new +\fIprocfs\fR instance on \fI/proc\fR for it. This is useful in environments +where mounting \fIprocfs\fR is not permitted, such as containers, where the +command would otherwise get a \fI/proc\fR view that doesn't match its own PID +namespace. Note that, without a PID namespace, processes started by the +command are not terminated once the command exits. + +This option can't be specified with a PID or with \-\-netns. + .TP .BR \-\-config-net Configure networking in the namespace: set up addresses and routes as configured diff --git a/passt.h b/passt.h index 51ccd4f..afd8e9f 100644 --- a/passt.h +++ b/passt.h @@ -195,6 +195,7 @@ struct ip6_ctx { * @pasta_ifn: Name of namespace interface for pasta * @pasta_ifi: Index of namespace interface for pasta * @pasta_conf_ns: Configure namespace after creating it + * @no_pidns: Don't create a new PID namespace for spawned command * @fwd: Forwarding tables * @fwd_pending: Pending forward tables * @no_tcp: Disable TCP operation @@ -278,6 +279,7 @@ struct ctx { char pasta_ifn[IF_NAMESIZE]; unsigned int pasta_ifi; int pasta_conf_ns; + bool no_pidns; struct fwd_table *fwd[PIF_NUM_TYPES]; struct fwd_table *fwd_pending[PIF_NUM_TYPES]; diff --git a/pasta.c b/pasta.c index 5aa56b7..2d916e1 100644 --- a/pasta.c +++ b/pasta.c @@ -194,15 +194,17 @@ static int pasta_spawn_cmd(void *arg) if (prctl(PR_SET_PDEATHSIG, SIGKILL)) die_perror("Couldn't set PR_SET_PDEATHSIG"); - /* We run in a detached PID and mount namespace: mount /proc over */ - if (mount("", "/proc", "proc", 0, NULL)) + a = (const struct pasta_spawn_cmd_arg *)arg; + + /* We run in a detached mount namespace, and, unless --no-pidns was + * given, in a detached PID namespace: mount /proc over + */ + if (!a->c->no_pidns && mount("", "/proc", "proc", 0, NULL)) warn_perror("Couldn't mount /proc"); if (write_file("/proc/sys/net/ipv4/ping_group_range", "0 0")) warn("Cannot set ping_group_range, ICMP requests might fail"); - a = (const struct pasta_spawn_cmd_arg *)arg; - conf_hostname_len = strlen(a->c->hostname); if (conf_hostname_len > 0) { if (sethostname(a->c->hostname, conf_hostname_len)) @@ -243,6 +245,7 @@ static int pasta_spawn_cmd(void *arg) void pasta_start_ns(struct ctx *c, uid_t uid, gid_t gid, bool config_idmaps, int argc, char *argv[]) { + int flags = CLONE_NEWIPC | CLONE_NEWNET | CLONE_NEWUTS | CLONE_NEWNS; char ns_fn_stack[NS_FN_STACK_SIZE] __attribute__ ((aligned(__alignof__(max_align_t)))); struct pasta_spawn_cmd_arg arg = { @@ -293,10 +296,11 @@ void pasta_start_ns(struct ctx *c, uid_t uid, gid_t gid, bool config_idmaps, sigaddset(&set, SIGUSR1); sigprocmask(SIG_BLOCK, &set, NULL); + if (!c->no_pidns) + flags |= CLONE_NEWPID; + pasta_child_pid = do_clone(pasta_spawn_cmd, ns_fn_stack, - sizeof(ns_fn_stack), - CLONE_NEWIPC | CLONE_NEWPID | CLONE_NEWNET | - CLONE_NEWUTS | CLONE_NEWNS | SIGCHLD, + sizeof(ns_fn_stack), flags | SIGCHLD, (void *)&arg); if (pasta_child_pid == -1) diff --git a/test/pasta_options/no_pidns b/test/pasta_options/no_pidns new file mode 100644 index 0000000..f565b2f --- /dev/null +++ b/test/pasta_options/no_pidns @@ -0,0 +1,25 @@ +# SPDX-License-Identifier: GPL-2.0-or-later +# +# PASST - Plug A Simple Socket Transport +# for qemu/UNIX domain socket mode +# +# PASTA - Pack A Subtle Tap Abstraction +# for network namespace/tap device mode +# +# test/pasta_options/no_pidns - Check --no-pidns handling + +htools readlink + +test Command is spawned in a new PID namespace by default +set PIDNS __STATEDIR__/pidns +set OUT __STATEDIR__/no-pidns.out +set ERR __STATEDIR__/no-pidns.err + +passt readlink /proc/self/ns/pid > __PIDNS__ +passt ./pasta -q -- readlink /proc/self/ns/pid > __OUT__ 2> __ERR__ +check [ "$(cat __PIDNS__)" != "$(cat __OUT__)" ] + +test --no-pidns keeps command in the caller's PID namespace +passt ./pasta -q --no-pidns -- readlink /proc/self/ns/pid > __OUT__ 2> __ERR__ +check [ "$(cat __PIDNS__)" = "$(cat __OUT__)" ] +check [ ! -s __ERR__ ] diff --git a/test/run b/test/run index c4073cc..14ddbbf 100755 --- a/test/run +++ b/test/run @@ -86,6 +86,7 @@ run() { setup pasta_options test pasta_options/log_to_file test pasta_options/netns_only + test pasta_options/no_pidns teardown pasta_options setup build -- 2.55.0

2 1

[PATCH] contrib/apparmor: add missing setfcap capability
by Sevinj Aghayeva 07 Sep '26

07 Sep '26

Since Linux 5.12, writing a mapping from UID 0 to /proc/self/uid_map requires CAP_SETFCAP. isolation.c already retains this capability for the case where pasta spawns a child from a non-init user namespace, but the AppArmor profile doesn't grant it, so the write is denied whenever the profile is enforced. Add setfcap to the AppArmor abstraction to match what isolation.c expects. Link: https://bugs.passt.top/show_bug.cgi?id=172 Signed-off-by: Sevinj Aghayeva <sevinj.aghayeva(a)gmail.com> --- contrib/apparmor/abstractions/passt | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/apparmor/abstractions/passt b/contrib/apparmor/abstractions/passt index 85bd1ee..f4570c1 100644 --- a/contrib/apparmor/abstractions/passt +++ b/contrib/apparmor/abstractions/passt @@ -24,6 +24,7 @@ capability setpcap, capability net_admin, capability sys_ptrace, + capability setfcap, userns, / r, # isolate_prefork(), isolation.c -- 2.43.0

1 0

[PATCH 0/7] Add vhost-net kernel support to pasta
by aerosouund 05 Sep '26

05 Sep '26

This work is based on the original v2 RFC by Eugenio Perez: Link: https://archives.passt.top/passt-dev/20250709174748.3514693-1-eperezma@redh… It is the first finished patch series for vhost-kernel support after a third RFC was submitted: Link: https://archives.passt.top/passt-dev/20260802132155.870796-1-aerosound161@g… vhost-net is a kernel device that allows reading and writing packets to a tap device using virtqueues instead of read(2), write(2), and their vectored counterparts. Frames are handed over through a shared descriptor ring, so several of them can be passed to the kernel at once rather than issuing a syscall per frame. The v3 RFC didn't yield any performance improvements because, to retain correctness, sends between pasta and the vhost-kernel thread had to be synchronous. This patch series fixes this problem through the changes introduced in the last commit, titled: "tap/tcp: Replace tcp_payload_used with a ring buffer style index" The changes reliably yield a roughly 2x speedup on the TX path (container to host). Numbers were obtained through iperf3 with the following methodology and results: Pasta command: ./pasta -f --runas 0:0 --map-guest-addr 192.168.0.5 --vhost-kernel on --config-net 2729785 Host: iperf3 -s1J Container: iperf3 -c 192.168.0.5 -t 10 -P4 -l 1M -w 32M -i1 With --vhost-kernel on: [SUM] 0.00-10.00 sec 1.36 GBytes 1.17 Gbits/sec 3643 sender [SUM] 0.00-10.00 sec 1.16 GBytes 999 Mbits/sec receiver With --vhost-kernel off: [SUM] 0.00-10.00 sec 700 MBytes 587 Mbits/sec 3556 sender [SUM] 0.00-10.10 sec 495 MBytes 411 Mbits/sec receiver Ammar Yasser (7): tap: Move the tap_hdr file to a separate file conf: Add context fields, epoll types and --vhost-kernel flag to pasta virtio: Add the pasta vhost-net interface and implementation tap: Implement the pasta vhost-net from-guest path tap, tcp, udp: Prepare the to-guest path for vhost-net tap: Implement the pasta vhost-net to-guest path tap/tcp: Replace tcp_payload_used with a ring buffer style index Makefile | 2 +- conf.c | 19 +++ epoll_type.h | 4 + passt.c | 9 ++ passt.h | 79 ++++++++++- tap.c | 364 ++++++++++++++++++++++++++++++++++++++++++++------- tap.h | 47 ++----- tap_hdr.h | 23 ++++ tcp_buf.c | 143 +++++++++++++++----- tcp_buf.h | 4 + udp.c | 41 ++++-- udp.h | 3 + util.c | 12 ++ util.h | 2 + vhost.c | 295 +++++++++++++++++++++++++++++++++++++++++ vhost.h | 79 +++++++++++ 16 files changed, 1002 insertions(+), 124 deletions(-) create mode 100644 tap_hdr.h create mode 100644 vhost.c create mode 100644 vhost.h -- 2.39.5 (Apple Git-154)

2 12

[PATCH] vhost_user: Reset vq enable flag in vu_cleanup()
by Laurent Vivier 03 Sep '26

03 Sep '26

vu_cleanup() resets most virtqueue state (started, notification, file descriptors) but does not reset the enable flag. After a QEMU disconnect and reconnect, the stale enable flag causes vu_set_vring_enable_exec() to hit its early return check (vq->enable == enable). Reset vq->enable to false in vu_cleanup() alongside the other virtqueue state. Signed-off-by: Laurent Vivier <lvivier(a)redhat.com> Reviewed-by: David Gibson <david(a)gibson.dropbear.id.au> --- vhost_user.c | 1 + 1 file changed, 1 insertion(+) diff --git a/vhost_user.c b/vhost_user.c index a1259c2624c0..272295f29db4 100644 --- a/vhost_user.c +++ b/vhost_user.c @@ -1081,6 +1081,7 @@ void vu_cleanup(struct vu_dev *vdev) struct vu_virtq *vq = &vdev->vq[i]; vq->started = false; + vq->enable = false; vq->notification = true; if (vq->call_fd != -1) { -- 2.55.0

1 0

[PATCH] netlink: Don't warn about multiple interfaces when there's only one
by Hayato Kiwata 01 Sep '26

01 Sep '26

Suppose there is a single network interface on the host, with two addresses of different prefixes assigned to it. In this situation, running pasta to create an isolated netns prints "Multiple interfaces with %s routes, picked first", even though there is in fact only one candidate interface. Reproducer: sudo ip link add dummy42 type dummy sudo ip link set dev dummy42 up sudo ip addr add fdaa:aaaa:aaaa::1/64 dev dummy42 sudo ip addr add fdbb:bbbb:bbbb::1/64 dev dummy42 pasta --config-net -- true This message is meant to indicate that there are multiple candidate interfaces, but in fact there is only one, which can mislead users. Therefore, avoid printing this message when there are multiple non-default routes that all belong to the same interface. Fixes: 450a6131beab ("netlink: With no default route, pick the first interface with a route") Signed-off-by: Hayato Kiwata <dev(a)haytok.jp> --- netlink.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/netlink.c b/netlink.c index 8d20dbb..225b666 100644 --- a/netlink.c +++ b/netlink.c @@ -271,6 +271,7 @@ unsigned int nl_get_ext_if(int s, sa_family_t af) }; unsigned defifi = 0, anyifi = 0; unsigned ndef = 0, nany = 0; + bool multi_anyif = false; struct nlmsghdr *nh; struct rtattr *rta; char buf[NLBUFSIZ]; @@ -330,6 +331,8 @@ unsigned int nl_get_ext_if(int s, sa_family_t af) nany++; if (!anyifi) anyifi = thisifi; + else if (anyifi != thisifi) + multi_anyif = true; } } @@ -345,7 +348,7 @@ unsigned int nl_get_ext_if(int s, sa_family_t af) } if (anyifi) { - if (nany > 1) { + if (multi_anyif) { info("Multiple interfaces with %s routes, picked first", af_name(af)); } -- 2.39.5 (Apple Git-154)

2 1

[PATCH v6 0/6] Add --dhcp-boot and --dhcp-opt options
by Anshu Kumari 26 Aug '26

26 Aug '26

This series adds support for custom DHCP options in passt, enabling network boot (PXE/UEFI HTTP Boot) and arbitrary DHCP option injection. Two new command-line flags are introduced: --dhcp-boot URL Sets the boot file URL (DHCP option 67 and the legacy boot file field) --dhcp-opt CODE,VALUE Sets any DHCP option by numeric code, with type-aware parsing per RFC 2132 The DHCP reply path is extended with option overload support (RFC 2132 option 52), allowing options to overflow into the file and sname fields when the standard options area is full. RFC 3396 option splitting for concatenation-requiring options has also been introduce as a separate patch. Anshu Kumari (6): dhcp: Refactor fill_one() to operate on a generic buffer dhcp: Add option state management with enum opt_state dhcp: Add option overload dhcp: Add --dhcp-opt with option table and value parser dhcp: Add --dhcp-boot command-line option dhcp: Add RFC 3396 option splitting for concatenation-requiring options conf.c | 31 +++- dhcp.c | 561 ++++++++++++++++++++++++++++++++++++++++++++++++++------ dhcp.h | 2 + passt.1 | 49 +++++ 4 files changed, 588 insertions(+), 55 deletions(-) -- 2.55.0

2 12

[PATCH v3 0/2] [PATCH 0/2] dhcpv6: Add --dhcpv6-opt for custom DHCPv6 options
by Anshu Kumari 25 Aug '26

25 Aug '26

This series adds a --dhcpv6-opt CODE,VALUE command-line option to inject custom options into DHCPv6 replies, complementing the existing --dhcp-opt support for DHCPv4. The primary use case is UEFI HTTP Boot, which requires Vendor Class (option 16) with the correct enterprise-number + length-prefixed wire encoding per RFC 8415 Section 21.16, and Boot File URL (option 59). Value formats are determined automatically from the option code via a type table. Supported types include plain strings, IPv6 addresses (single and list), 8/16/32-bit integers, vendor class (ENTERPRISE:DATA), and length-prefixed string lists. Anshu Kumari (2): dhcpv6: Add --dhcpv6-opt with option type table and value parser dhcpv6: Inject custom options into DHCPv6 replies conf.c | 25 +++- dhcpv6.c | 363 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ dhcpv6.h | 2 + passt.1 | 31 +++++ 4 files changed, 420 insertions(+), 1 deletion(-) -- 2.55.0

2 4

[PATCH 0/5] Settings for Zed editor and minor fixups
by David Gibson 21 Aug '26

21 Aug '26

I've been playing with the Zed editor again. It's default settings don't quite match passt's style, so add a config file to make it do the right thing. Also update some of the config for clangd to suppress bogus warnings the way Zed invokes it. Between them these also found a handful of minor but real code warts, so fix those, too. David Gibson (5): clangd: Add _GNU_SOURCE to default clangd options util: Eliminate a stray trailing whitespace util: Add missing O_CLOEXEC for !HAS_GETRANDOM path util, pasta: Remove some unneeded #includes Add Zed editor settings .clangd | 2 +- .zed/settings.json | 4 ++++ pasta.c | 1 - util.c | 7 ++----- 4 files changed, 7 insertions(+), 7 deletions(-) create mode 100644 .zed/settings.json -- 2.53.0

2 5

[PATCH 3/5] util: Add missing O_CLOEXEC for !HAS_GETRANDOM path
by David Gibson 21 Aug '26

21 Aug '26

It rarely matters, since we usually have getrandom(), but in case we don't our open() of /dev/random was missing O_CLOEXEC, which can cause clang warnings. Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/util.c b/util.c index 500e8f55..df972a05 100644 --- a/util.c +++ b/util.c @@ -964,7 +964,7 @@ void raw_random(void *buf, size_t buflen) { size_t random_read = 0; #ifndef HAS_GETRANDOM - int fd = open(DEV_RANDOM, O_RDONLY); + int fd = open(DEV_RANDOM, O_RDONLY | O_CLOEXEC); if (fd < 0) die_perror("Couldn't open %s", DEV_RANDOM); -- 2.53.0

2 1