artifacts VS gvisor

One of the most interesting/unique features is the integration with OCI-compatible container registries. Tart can pull/push virtual machines from/to a registry. This feature was inspired by OCI Artifacts initiative.

There's two major production-ready Go-based operating system(-ish) projects:

- Google's gVisor[1] (a re-implementation of a significant subset of the Linux syscall ABI for isolation, also mentioned in the article)

- USBArmory's Tamago[2] (a single-threaded bare-metal Go runtime for SOCs)

Both of these are security-focused with a clear trade off: sacrifice some performance for memory safe and excellent readability (and auditability). I feel like that's the sweet spot for low-level Go - projects that need memory safety but would rather trade some performance for simplicity.

[1]: https://github.com/google/gvisor

[2]: https://github.com/usbarmory/tamago

It uses gVisor to create a TCP/IP stack in userspace, and starts a wireguard interface on it, which the HTTP server from http.Serve listens on. The library will print a URL after startup, where you can access your server. You can create multiple listeners in one binary.

The playground compiles the program with GOOS=linux, GOARCH=amd64 and runs the program with gVisor. Detailed documentation is available at the gVisor site.

You could use a container sandbox like gVisor, light virtual machines as containers (Kata containers, firecracker + containerd) or full virtual machines (virtlet as a CRI).

An analogous project from Google with similar use cases is gvisor, which IIRC underlies Cloud Run: https://gvisor.dev/

Yeah, runtimeClass lets you specify which CRI plugin you want based on what you have available. Here's an example from the containerd documentation - you could have one node that can run containers under standard runc, gvisor, kata containers, or WASM. Without runtimeClass, you'd need either some form of custom solution or four differently configured nodes to run those different runtimes. That's how krustlet did it - you'd have kubelet/containerd nodes and krustlet/wasm nodes, and could only run the appropriate workload on each node type.

It all depends on your use-case and expectations. You should definitely check out gvisor. It creates a userpace isolated kernels for every container, thus making it sandboxed. The workloads then still run inside a container, not a stripped down OCI compatible VM as in kata.

The Linux kernel has a huge attack surface, and privilege escalation vulnerabilities abound. This is why https://gvisor.dev/ exists - it's a memory-safe proxy for Linux syscalls. This is also why Chrome OS runs its Linux environment in a custom hypervisor written in Rust instead of containers.

I can chime in with some optimizations (linux).

For normal UDP sockets UDP_GRO and UDP_SEGMENT can be faster than sendmmsg/recvmmsg.

In Gvisor they decided that read/write from tun is slow so they did PACKET_MMAP on raw socket instead. AFAIU they just ignore tap device and run a raw socket on it. Dumping packet from raw socket has faster interface than the device itself.

https://github.com/google/gvisor/blob/master/pkg/tcpip/link/...