[Feature Request] Userspace networking (passt/slirp)

[aerosouund]

Feature Request

Allow firecracker to delegate VM networking to a userspace process. This can be highly beneficial in low privilege scenarios where CAP_NET_ADMIN is not available and makes VM config a lot faster (no iptables/nftables work required)
I would love to discuss any blockers you think might be present that may prevent this feature from being feasible
If there's not any, i'd be happy to work on a PR!

Describe possible alternatives

N/A

Additional context

N/A

Checks

• Have you searched the Firecracker Issues database for similar requests?
• Have you read all the existing relevant Firecracker documentation?
• Have you read and understood Firecracker's core tenets?

[ShadowCurse]

Hi @aerosouund, this seems like an interesting idea. Can you share more information about the use-cases use would use this for? Also can you share more info about the general architecture of passt/slirp networking and how should it work with Firecracker?

[aerosouund]

@ShadowCurse
Sure, passt will create a socket that serves as the communication channel with the VMM network device. When the VMM reads packets from the guest virtqueue, it writes those packets to this socket. passt then takes the Ethernet frames the guest is sending, strips the L2 headers, and translates the L3/L4 traffic into unprivileged host socket calls, effectively bridging the guest's network stack to the host without requiring elevated privileges. When data returns from the remote end, passt writes it back to the socket as Ethernet frames; the VMM reads them and pushes the packets into the guest virtqueue.
Currently, the Firecracker netdev only accepts a Tap as its backend. The core of the change would be to introduce an abstract backend type, so the netdev can be backed by either a Unix domain socket or a tap device.

The use cases are:

• The ability to run microVMs in environments without CAP_NET_ADMIN, the most common scenario being inside a container.
• The ability to spin up internet-connected VMs without any iptables setup, which lowers the barrier for experimentation.

For context on why passt was created: KubeVirt VMs can't participate in a service mesh the way a normal Kubernetes pod can. This talk covers the problem in depth, but briefly.. with bridge binding between the pod and VM interface, sidecar proxies can't intercept traffic at all. With masquerade binding, traffic is NAT'd via iptables before it reaches the sidecar, so the proxy never gets a chance to intercept it. passt sidesteps both problems by handling networking entirely in userspace.
The passt authors also have a PoC for Kata Containers, and passt support has since been making its way into Kata's network model. Having Firecracker's network backend abstracted now would reduce the cost of a similar integration if and when it becomes relevant.