passt/pif.c, branch 2026_05_07.1afd4ed

pif: Limit pif names to 128 bytes

2026-05-07T06:06:30+00:00

All current pif names are quite short, and we expect them to remain short
when/if we allow arbitrary pifs.  However, because of the structure of
the current code we don't enforce any limit on the length.

This will become more important with dynamic configuration updates, so
start enforcing a length limit.  Specifically we allow pif names to be up
to 128 bytes (PIF_NAME_SIZE), including the terminating \0.  This is
more or less arbitrary, but seems like it should be comfortably enough for
all the cases we have in mind.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
[sbrivio: Fixed typo in comment, reported by Laurent]
Signed-off-by: Stefano Brivio

treewide: Spell ASSERT() as assert()

2026-03-20T20:05:29+00:00

The standard library assert(3), at least with glibc, hits our seccomp
filter and dies with SIGSYS before it's able to print a message, making it
near useless.  Therefore, since 7a8ed9459dfe ("Make assertions actually
useful") we've instead used our own implementation, named ASSERT().

This makes our code look slightly odd though - ASSERT() has the same
overall effect as assert(), it's just a different implementation.  More
importantly this makes it awkward to share code between passt/pasta proper
and things that compile in a more typical environment.  We're going to want
that for our upcoming dynamic configuration tool.

Address this by overriding the standard library's assert() implementation
with our own, instead of giving ours its own name.

The standard assert() is supposed to be omitted if NDEBUG is defined,
which ours doesn't do.  Implement that as well, so ours doesn't
unexpectedly differ.  For the -DNDEBUG case we do this by *not* overriding
assert(), since it will be a no-op anyway.  This requires a few places to
add a #include  to let us compile (albeit with warnings) when
-DNDEBUG.

Signed-off-by: David Gibson 
[sbrivio: Fix some conflicts and missing conversions as a result of
 applying "vu_common: Move iovec management into vu_collect()" first]
Signed-off-by: Stefano Brivio

fwd, pif: Replace with pif_sock_l4() with pif_listen()

2026-03-04T16:52:55+00:00

It turns out all users of pif_sock_l4() use it for "listening" sockets,
which now all have a common epoll reference format.  We can take advantage
of that to pass the necessary epoll information into pif_sock_l4() in a
more natural way, rather than as an opaque u32.

That in turn allows union fwd_listen_ref can become a struct, since the
union only exist to allow the meaningful fields to be coerced into a u32
for pif_sock_l4().

Rename pif_sock_l4() to pif_listen() to reflect the new semantics.  While
we're there, remove the static_assert() on the fwd_listen_ref's size.  We
do still need it to fit into 32 bits, but that constraint is imposed only
by the fact that it needs to fit into the whole, epoll_ref structure,
which we already check with a static_assert() in epoll_ctl.h.

Signed-off-by: David Gibson 
Reported-by: Peter Foley 
Signed-off-by: Stefano Brivio

pif: Correctly set scope_id for guest-side link local addresses

2025-12-10T07:37:29+00:00

pif_sockaddr() is supposed to generate a suitable socket address, either
for the host, or for the guest, depending on the 'pif' parameter.  When
given a link-local address, this means it needs to generate a suitable
scope_id to specify which link.  It does this for the host, but not for the
guest.

I think this was done on the assumption that we won't ever generate guest
side link local addresses when forwarding connections.  That, however, is
not the case, at least with the recent extensions to "local mode".  Fix the
problem by properly populating the scope_id field for guest addresses.

Link: https://bugs.passt.top/show_bug.cgi?id=181
Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

util: Rename sock_l4_dualstack() to sock_l4_dualstack_any()

2025-12-02T22:07:36+00:00

Stefano correctly noted that the fact a socket is dual-stack doesn't
necessarily imply that it is bound to a wildcard address.  While that's the
only case we use for dual-stack sockets, there may be others.  Therefore
rename this function to make it clearer that it always uses a wildcard
bind.

Suggested-by: Stefano Brivio 
Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

tcp, udp: Bind outbound listening sockets by interface instead of address

2025-12-02T22:07:34+00:00

Currently, outbound forwards (-T, -U) are handled by sockets bound to the
loopback address.  Typically we create two sockets, one for 127.0.0.1 and
one for ::1.

This has some disadvantages:
 * The guest can't connect via 127.0.0.0/8 addresses other than 127.0.0.1
 * We can't use dual-stack sockets, we have to have separate sockets for
   IPv4 and IPv6.

The restriction exists for a reason though.  If the guest has any
interfaces other than pasta (e.g. a VPN tunnel) external hosts could reach
the host via the forwards.  Especially combined with -T auto / -U auto this
would make it very easy to make a mistake with nasty security implications.

We can achieve this a different way, however.  Don't bind to a specific
address, but _do_ use SO_BINDTODEVICE to restrict the sockets to the "lo"
interface.  We fall back to the old behaviour for older kernels where
SO_BINDTODEVICE is not available unprivileged.

Note that although traffic to a local but non-loopback address is passed
over the 'lo' interface (as seen by netfilter and dumpcap), it doesn't
count as attached to that interface for the purposes of SO_BINDTODEVICE
(information from the routing table overrides the "physical" interface).
So, this change doesn't help for bug 100.

It's also not a complete fix for bug 113, it does however:
 * Get us a step closer to fixing bug 113
 * Slightly simplify the code
 * Make things a bit easier to allow more flexible binding on the guest in
   in future

Link: https://bugs.passt.top/show_bug.cgi?id=113

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

util, flow, pif: Simplify sock_l4_sa() interface

2025-12-02T22:07:17+00:00

sock_l4_sa() has a somewhat confusing 'v6only' option controlling whether
to set the IPV6_V6ONLY socket option.  Usually it's set when the given
address is IPv6, but not when we want to create a dual stack listening
socket.  The latter only makes sense when the address is :: however.

Clarify this by only keeping the v6only option in an internal helper
sock_l4_().  External users will call either sock_l4() which always creates
a socket bound to a specific IP version, or sock_l4_dualstack() which
creates a dual stack socket, but takes only a port not an address.

We drop the '_sa' suffix while we're at it - it exists because this used
to be an internal version with a sock_l4() wrapper.  The wrapper no longer
exists so the '_sa' is no longer useful.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

inany: Let length of sockaddr_inany be implicit from the family

2025-12-02T22:07:14+00:00

sockaddr_inany can contain either an IPv4 or IPv6 socket address, so the
relevant length for bind() or connect() can vary.  In pif_sockaddr() we
return that length, and in sock_l4_sa() we take it as an extra parameter.

However, sockaddr_inany always contains exactly a sockaddr_in or a
sockaddr_in6 each with a fixed size.  Therefore we can derive the relevant
length from the family, and don't need to pass it around separately.

Make a tiny helper to get the relevant address length, and update all
interfaces to use that approach instead.

In the process, fix a buglet in tcp_flow_repair_bind(): we passed
sizeof(union sockaddr_inany) to bind() instead of the specific length for
the address family.  Since the sizeof() is always longer than the specific
length, this is probably fine, but not theoretically correct.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

util: Move epoll registration out of sock_l4_sa()

2025-10-30T14:32:30+00:00

Move epoll_add() calls from sock_l4_sa() to the protocol-specific code
(icmp.c, pif.c, udp_flow.c) to give callers more control over epoll
registration. This allows sock_l4_sa() to focus solely on socket
creation and binding, while epoll management happens at a higher level.

Remove the data parameter from sock_l4_sa() and flowside_sock_l4() as
it's no longer needed - callers now construct the full epoll_ref and
register the socket themselves after creation.

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

util, pif: Replace sock_l4() with pif_sock_l4()

2024-09-25T17:03:15+00:00

The sock_l4() function is very convenient for creating sockets bound to
a given address, but its interface has some problems.

Most importantly, the address and port alone aren't enough in some cases.
For link-local addresses (at least) we also need the pif in order to
properly construct a socket adddress.  This case doesn't yet arise, but
it might cause us trouble in future.

Additionally, sock_l4() can take AF_UNSPEC with the special meaning that it
should attempt to create a "dual stack" socket which will respond to both
IPv4 and IPv6 traffic.  This only makes sense if there is no specific
address given.  We verify this at runtime, but it would be nicer if we
could enforce it structurally.

For sockets associated specifically with a single flow we already replaced
sock_l4() with flowside_sock_l4() which avoids those problems.  Now,
replace all the remaining users with a new pif_sock_l4() which also takes
an explicit pif.

The new function takes the address as an inany *, with NULL indicating the
dual stack case.  This does add some complexity in some of the callers,
however future planned cleanups should make this go away again.

Signed-off-by: David Gibson