Passt: Plug a Simple Socket Transport
Plug A Simple Socket Transport





passt implements a translation layer between a Layer-2 network interface and
native Layer-4 sockets (TCP, UDP, ICMP/ICMPv6 echo) on a host. It doesn't
require any capabilities or privileges, and it can be used as a simple
replacement for Slirp.


  
  
  


    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    





pasta: Pack A Subtle Tap Abstraction
pasta (same binary as passt, different command) offers equivalent
functionality, for network namespaces: traffic is forwarded using a tap
interface inside the namespace, without the need to create further interfaces on
the host, hence not requiring any capabilities or privileges.
It also implements a tap bypass path for local connections: packets with a local
destination address are moved directly between Layer-4 sockets, avoiding Layer-2
translations, using the splice(2) and recvmmsg(2)/sendmmsg(2) system calls
for TCP and UDP, respectively.


  
  
  




Motivation
Features
Interfaces and Environment
Services
Addresses
Protocols
Ports
Demo
Continuous Integration
Performance
Try it
Contribute
Security and Vulnerability Reports

See also the man page.
Motivation
passt
When container workloads are moved to virtual machines, the network traffic is
typically forwarded by interfaces operating at data link level. Some components
in the containers ecosystem (such as service meshes), however, expect
applications to run locally, with visible sockets and processes, for the
purposes of socket redirection, monitoring, port mapping.
To solve this issue, user mode networking, as provided e.g. by libslirp,
can be used. Existing solutions implement a full TCP/IP stack, replaying traffic
on sockets that are local to the pod of the service mesh. This creates the
illusion of application processes running on the same host, eventually separated
by user namespaces.
While being almost transparent to the service mesh infrastructure, that kind of
solution comes with a number of downsides:

three different TCP/IP stacks (guest, adaptation and host) need to be
  traversed for every service request
addressing needs to be coordinated to create the pretense of consistent
  addresses and routes between guest and host environments. This typically needs
  a NAT with masquerading, or some form of packet bridging
the traffic seen by the service mesh and observable externally is a distant
  replica of the packets forwarded to and from the guest environment:
TCP congestion windows and network buffering mechanisms in general operate
    differently from what would be naturally expected by the application
protocols carrying addressing information might pose additional challenges,
    as the applications don't see the same set of addresses and routes as they
    would if deployed with regular containers

passt implements a thinner layer between guest and host, that only implements
what's strictly needed to pretend processes are running locally. The TCP
adaptation doesn't keep per-connection packet buffers, and reflects observed
sending windows and acknowledgements between the two sides. This TCP adaptation
is needed as passt runs without the CAP_NET_RAW capability: it can't create
raw IP sockets on the pod, and therefore needs to map packets at Layer-2 to
Layer-4 sockets offered by the host kernel.
See also a
detailed illustration
of the problem and what lead to this approach.
pasta
On Linux, regular users can create network namespaces and run application
services inside them. However, connecting namespaces to other namespaces and to
external hosts requires the creation of network interfaces, such as veth
pairs, which needs in turn elevated privileges or the CAP_NET_ADMIN
capability. pasta, similarly to slirp4netns, solves this problem by creating
a tap interface available to processes in the namespace, and mapping network
traffic outside the namespace using native Layer-4 sockets.
Existing approaches typically implement a full, generic TCP/IP stack for this
translation between data and transport layers, without the possibility of
speeding up local connections, and usually requiring NAT. pasta:

avoids the need for a generic, full-fledged TCP/IP stack by coordinating TCP
  connection dynamics between sender and receiver
offers a fast bypass path for local connections: if a process connects to
  another process on the same host across namespaces, data is directly forwarded
  using pairs of Layer-4 sockets
with default options, maps routing and addressing information to the
  namespace, avoiding any need for NAT

Features
✅: done/supported, ❌: out of scope, 🛠: in progress/being considered
⌚: nice-to-have, eventually
Protocols

✅ IPv4
✅ all features, except for
❌ fragmentation


✅ IPv6
✅ all features, except for
❌ fragmentation
❌ jumbograms


✅ TCP
✅ Window Scaling (RFC 7323)
✅ Defenses against Sequence Number Attacks (RFC 6528)
⌚ Protection Against Wrapped Sequences (PAWS, RFC 7323)
⌚ Timestamps (RFC 7323)
❌ Selective Acknowledgment (RFC 2018)


✅ UDP
✅ ICMP/ICMPv6 Echo
⌚ IGMP/MLD proxy
⌚ SCTP

Portability

Linux
✅ starting from 4.18 kernel version
✅ starting from 3.13 kernel version


✅ run-time selection of AVX2 build
C libraries:
✅ glibc
✅ musl
⌚ uClibc-ng


⌚ FreeBSD,
  Darwin
⌚ NetBSD,
  OpenBSD
⌚ Win2k

Security

✅ no dynamic memory allocation (sbrk(2), brk(2), mmap(2) blocked via
  seccomp)
✅ root operation not allowed outside user namespaces
✅ all capabilities dropped, other than CAP_NET_BIND_SERVICE (if granted)
✅ with default options, user, mount, IPC, UTS, PID namespaces are detached
✅ no external dependencies (other than a standard C library)
✅ restrictive seccomp profiles (30 syscalls allowed for passt, 41 for
  pasta on x86_64)
✅ examples of AppArmor and
  SELinux profiles available
✅ static checkers in continuous integration (clang-tidy, cppcheck)
✅️ clearly defined boundary-checked packet abstraction
🛠️ ~5 000 LoC target
⌚ fuzzing, packetdrill tests
⌚ stricter synflood protection
💡 add your
  ideas

Configurability

✅ all addresses, ports, port ranges
✅ optional NAT, not required
✅ all protocols
✅ pasta: auto-detection of bound ports
⌚ run-time configuration of port ranges without autodetection
⌚ configuration of port ranges for autodetection
💡 add your
  ideas

Performance

✅ maximum two (cache hot) copies on every data path
✅ pasta: zero-copy for local connections by design (no configuration
  needed)
✅ generalised coalescing and batching on every path for every supported
  protocol
✅ 4 to 50 times IPv4 TCP throughput of existing, conceptually similar
  solutions depending on MTU (UDP and IPv6 hard to compare)
🛠 vhost-user support for
  maximum one copy on every data path and lower request-response latency
⌚ multithreading
⌚ raw IP socket support if
  CAP_NET_RAW is granted
⌚ eBPF support (might not improve performance over vhost-user)

Interfaces

✅ native qemu support (passt)
✅ native libvirt support
  (passt)
✅ Podman integration
  (pasta)
✅ bug-to-bug compatible
  slirp4netns replacement
✅ out-of-tree patch for
  Kata Containers available
✅ rootless Docker
  network back-end
  via moby/rootlesskit

Availability

official packages for:
✅ Alpine Linux
✅ Arch Linux (aarch64, i486)
✅ CentOS Stream
✅ Debian
✅ Fedora
✅ Gentoo
✅ GNU Guix
✅ OpenSUSE
✅ Ubuntu
✅ Void Linux


unofficial packages for:
✅ EPEL, Mageia


✅ unofficial packages from x86_64
  static builds for other RPM-based distributions
✅ unofficial packages from x86_64
  static builds for other Debian-based distributions
✅ testing on non-x86_64 architectures (aarch64, armv7l, i386, ppc64, ppc64le,
  s390x)

Services

✅ built-in ARP proxy
✅ minimalistic DHCP server
✅ minimalistic NDP proxy with router advertisements and
  SLAAC support
✅ minimalistic DHCPv6 server
⌚ fine-grained configurability of DHCP, NDP, DHCPv6 options

Interfaces and Environment
passt exchanges packets with qemu via UNIX domain socket, using the socket
back-end in qemu. This is supported since qemu 7.2.
For older versions, the qrap wrapper can be used to
connect to a UNIX domain socket and to start qemu, which can now use the file
descriptor that's already opened.
This approach, compared to using a tap device, doesn't require any security
capabilities, as we don't need to create any interface.
pasta runs out of the box with any recent (post-3.8) Linux kernel.
Services
passt and pasta provide some minimalistic implementations of networking
services:

ARP proxy, that resolves the address of
  the host (which is used as gateway) to the original MAC address of the host
DHCP server, a simple implementation
  handing out one single IPv4 address to the guest or namespace, namely, the
  same address as the first one configured for the upstream host interface, and
  passing the nameservers configured on the host
NDP proxy, which can also assign prefix
  and nameserver using SLAAC
DHCPv6 server: a simple
  implementation handing out one single IPv6 address to the guest or namespace,
  namely, the same address as the first one configured for the upstream host
  interface, and passing the nameservers configured on the host

Addresses
For IPv4, the guest or namespace is assigned, via DHCP, the same address as the
upstream interface of the host, and the same default gateway as the default
gateway of the host. Addresses are translated in case the guest is seen using a
different address from the assigned one.
For IPv6, the guest or namespace is assigned, via SLAAC, a prefix derived from
the address of the upstream interface of the host, the same default route as the
default route of the host, and, if a DHCPv6 client is running in the guest or
namespace, also the same address as the upstream address of the host. This means
that, with a DHCPv6 client in the guest or namespace, addresses don't need to be
translated. Should the client use a different address, the destination address
is translated for packets going to the guest or to the namespace.
Local connections with passt
For UDP and TCP, for both IPv4 and IPv6, packets from the host addressed to a
loopback address are forwarded to the guest with their source address changed to
the address of the gateway or first hop of the default route. This mapping is
reversed on the other way.
Local connections with pasta
Packets addressed to a loopback address in either namespace are directly
forwarded to the corresponding (or configured) port in the other namespace.
Similarly as passt, packets from the non-init namespace addressed to the
default gateway, which are therefore sent via the tap device, will have their
destination address translated to the loopback address.
Protocols
passt and pasta support TCP, UDP and ICMP/ICMPv6 echo (requests and
replies). More details about the TCP implementation are described in the
theory of operation, and similarly for
UDP.
An IGMP/MLD proxy is currently work in progress.
Ports
passt
To avoid the need for explicit port mapping configuration, passt can bind to
all unbound non-ephemeral (0-49152) TCP and UDP ports. Binding to low ports
(0-1023) will fail without additional capabilities, and ports already bound
(service proxies, etc.) will also not be used. Smaller subsets of ports, with
port translations, are also configurable.
UDP ephemeral ports are bound dynamically, as the guest uses them.
If all ports are forwarded, service proxies and other services running in the
container need to be started before passt starts.
pasta
With default options, pasta scans for bound ports on init and non-init
namespaces, and automatically forwards them from the other side. Port forwarding
is fully configurable with command line options.
Demo
pasta







passt




Continuous Integration





See also the test logs.
Performance


Try it
passt


build from source:
git clone https://passt.top/passt
cd passt
make




alternatively, install one of the available packages
Static binaries and packages are simply built with:






have a look at the man page for synopsis and options:




run the demo script, that detaches user and network namespaces, configures the
  new network namespace using pasta, starts passt and, optionally, qemu:




alternatively, you can use
  libvirt
  to start QEMU


and that's it, you should now have TCP connections, UDP, and ICMP/ICMPv6
  echo working from/to the guest for IPv4 and IPv6


to connect to a service on the VM, just connect to the same port directly
  with the address of the current network namespace


pasta


build from source:
git clone https://passt.top/passt
cd passt
make




alternatively, install one of the available packages
Static binaries and packages are simply built with:






have a look at the man page for synopsis and options:




start pasta with:



alternatively, use it directly with Podman (since Podman 4.3.2, or with
  commit aa47e05ae4a0):podman run --net=pasta ...






you're now inside a new user and network namespace. For IPv6, SLAAC happens
  right away as pasta sets up the interface, but DHCPv6 support is available
  as well. For IPv4, configure the interface with a DHCP client:


and, optionally:




alternatively, start pasta as:


to let pasta configure networking in the namespace by itself, using
netlink


...or run the demo script:






and that's it, you should now have TCP connections, UDP, and ICMP/ICMPv6
  echo working from/to the namespace for IPv4 and IPv6


to connect to a service inside the namespace, just connect to the same port
  using the loopback address.


Contribute
Mailing Lists


Submit, review patches, and discuss development ideas on
  passt-dev


Ask your questions and discuss usage needs on
  passt-user


Bug Reports and Feature Requests

Pick up an open bug
Implement a feature request
Browse all open items
...or file a bug

Chat

Somebody might be available on IRC on #passt at
  Libera.Chat

Weekly development meeting

Open to everybody! Feel free to join and propose a different time directly on
  the agenda.

Security and Vulnerability Reports

Please send an email to passt-sec, private list,
  no subscription required
