krun: switch to passt-based networking

[slp]

Automatically start passt and use it for adding a virtio-net interface to the microVM. This allows us to have networking even when running generic kernels that doesn't support TSI.

Summary by Sourcery

Integrate passt-based networking into the krun handler by forking and exec’ing passt, wiring up a Unix stream socket for virtio-net via krun_add_net_unixstream, and updating file-descriptor management to support the new passt sockets.

New Features:

• Automatically launch the passt daemon and create a Unix stream socket pair for microVM networking
• Invoke krun_add_net_unixstream to attach a virtio-net interface over the passt socket
• Add a close_fds handler to properly close or preserve file descriptors after spawning passt

Enhancements:

• Delegate container startup’s file-descriptor cleanup to the handler’s close_fds hook when available

[sourcery-ai]

Reviewer's Guide

The PR integrates passt-based networking by launching a passt daemon with a UNIX socketpair, attaching a virtio-net interface to the microVM via krun_add_net_unixstream, and extending FD cleanup to preserve passt sockets.

File-Level Changes

Change	Details	Files
Automatically start passt daemon and manage its socketpair	define PASST_FD_PARENT and PASST_FD_CHILD constants add passt_fds array to krun_config implement libkrun_start_passt to socketpair, fork+exec passt, and sync startup invoke libkrun_start_passt in configure_container phase	src/libcrun/handlers/krun.c
Attach virtio-net interface via krun_add_net_unixstream	include <sys/socket.h> add krun_add_net_unixstream function pointer and dlsym lookup call krun_add_net_unixstream with parent FD, MAC, features, and flags	src/libcrun/handlers/krun.c
Preserve passt FDs during FD cleanup with new close_fds hook	add close_fds callback to custom_handler vtable implement libkrun_close_fds to skip passt socketpair FDs when closing modify container_init to call custom close_fds if available	src/libcrun/handlers/krun.c src/libcrun/container.c src/libcrun/custom-handler.h

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[slp]

cc/ @sbrivio-rh for awareness

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[sbrivio-rh]

Actually, you can skip this whole dance by not passing -f: passt behaves like usual UNIX daemons and forks into background when it's ready, and if you give -1 / --one-off, it terminates by itself once the guest disconnects.

Conversely, getting something from its stdout doesn't guarantee that it's ready. Which is the only (minor) issue I spotted here, by the way, so if you need to stick to this approach for whatever reason it looks fine to me as well.

[svenstaro]

I think this would be amazing to have in crun! I did apply and run your patch and I can confirm that passt is started along with my container. Inside my container, however, networking doesn't appear to be configured:

2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 5a:94:ef:e4:0c:ee brd ff:ff:ff:ff:ff:ff

and I can't reach the network at all.

I'm launching my container like this:

podman run --net pasta --runtime krun -it --rm archlinux /bin/bash

Do I need some extra stuff?

[sbrivio-rh]

I think this would be amazing to have in crun! I did apply and run your patch and I can confirm that passt is started along with my container. Inside my container, however, networking doesn't appear to be configured

With Podman and pasta(1), you get networking automatically configured because Podman passes --config-net.

But there's no such thing in passt(1) as it can't magically enter your VM and do stuff there, so you need to use DHCP or SLAAC/NDP to configure the network in this case (ip link set dev eth0 up should give you IPv6 connectivity, and dhcpcd or dhclient after that should give you IPv4).

Maybe an approach similar to AsahiLinux/muvm#111 (tiny DHCP client embedded in muvm) would make sense here as well.

[svenstaro]

Ah right, that makes a lot of sense. Sadly, it doesn't work:

dhclient -v
...
Listening on LPF/eth0/5a:94:ef:e4:0c:ee
Sending on   LPF/eth0/5a:94:ef:e4:0c:ee
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 21
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

EDIT:
Ah, huh. On VM/container restart, it now works. Weird. It also keeps working now. No idea what kind of fluke that was!

[sbrivio-rh]

Ah, huh. On VM/container restart, it now works. Weird. It also keeps working now. No idea what kind of fluke that was!

It might be that you forgot to bring the interface up first? dhclient won't do it for you.

[slp]

Maybe an approach similar to AsahiLinux/muvm#111 (tiny DHCP client embedded in muvm) would make sense here as well.

That's exactly what I was planning to do, basically by translating your Rust implementation into C for init/init.c.

[sbrivio-rh]

That's exactly what I was planning to do, basically by translating your Rust implementation into C for init/init.c.

By the way, if you're looking for some quick-and-dirty netlink implementation, without using the full libnl, with pretty much just the parts you need to do that, you can probably draw some inspiration from https://passt.top/passt/tree/netlink.c or https://archives.passt.top/passt-dev/20231206160808.3d312733@elisabeth/.

It's GPL code though, so you can't use it directly in libkrun's init (init/init.c is missing licensing information by the way). But I hope it helps anyway as documentation / how-to. Or maybe it's just more convenient to go with libnl, after all...