[HN Gopher] Gvisor on Raspbian
___________________________________________________________________
Gvisor on Raspbian
Author : _ananos_
Score : 61 points
Date : 2026-03-13 10:08 UTC (12 hours ago)
(HTM) web link (nubificus.co.uk)
(TXT) w3m dump (nubificus.co.uk)
| geerlingguy wrote:
| > Fair warning: compiling a kernel on the Pi itself takes several
| hours.
|
| One nit: this should only take about 40 minutes on a Pi 5,
| assuming you're compiling with -j6 to use all the cores.
|
| (Still faster to cross-compile)
| _ananos_ wrote:
| well, the tricky detail here (which we do not mention in the
| post, our bad) is that we got the raspbian config (cp
| /boot/config ... .config && make oldconfig) which includes most
| modules, and that's why it took more.
|
| But yeap, good point about using the -j flag, it really
| accelerates the build!
| bionade24 wrote:
| Using distcc networked compilation instead of cross-compiling
| is reasonably fast too and easier to set up if one isn't
| familiar with either.
| uber1024 wrote:
| the most frustrating part with having to compile a custom
| kernel is the maintenance burden (packaging/updating etc.),
| and not the time it takes to build...
|
| I had a similar issue with networking modules for calico (k8s
| cni) on both rpis and jetson boards...
| pelcg wrote:
| That is kind of what I was thinking too, and cross-compilation
| is still the fastest way to build for a different target.
| pelcg wrote:
| What use-cases are there for gVisor on Raspbian, given that the
| target is a Raspberry Pi?
| _ananos_ wrote:
| the simplest one (and the one we're targetting) is multi-tenant
| services. You want to sandbox your service so that it doesn't
| affect the rest of the services running.
|
| <shameless plug> We're building a container runtime to do this,
| and we are comparing alternatives, that's how we got there:
| https://github.com/urunc-dev/urunc</shameless plug>
| 0x457 wrote:
| > given that the target is a Raspberry Pi?
|
| Why one would use gVisor is clear, but why would one do that
| in RPi?
| _ananos_ wrote:
| a number of reasons -- power budget, form factor,
| experimenting as a testbed for more "elaborate" setups
| (like robotics combined with a low-end TPU like the coral,
| or a jetson nano)
|
| consider that you can take advantage of all the cloud-
| native goodies, all wrapped up in a 10x5 box with 5-10W (or
| 25-30W if you consider jetson boards).
| Lliora wrote:
| Ran gVisor on a Pi 4 cluster for home IoT sandboxing. Memory
| overhead is real--about 120MB per sandbox vs 15MB for raw
| containers. On 4GB boards that limits you to ~25 isolated
| services before OOM kicks in. Also, syscallLan Jie adds 30-40%
| CPU overhead on ARM. Works fine for untrusted Python scripts, but
| I wouldn't run anything compute-heavy.
| eptcyka wrote:
| Wouldn't compute workloads be fine as they should not be
| syscall bound?
| _ananos_ wrote:
| yeap -- compute would be nearly the same. I suspect you need
| some kind of I/O to make your compute useful (get input for
| the computation / produce output etc.) so, still, this would
| have a negative effect overall.
| bitwize wrote:
| gVisor's architecture is fascinating. Years ago I wrote an essay
| that was kind of a response to all the cracks about "systemd-
| kerneld" that have been made over the years. Written in character
| as "Fake Lennart Poettering", it proposed a strategy, using
| techniques inspired by NetBSD's rump kernel libraries, to turn
| systemd into a kernel, which would then load a Linux image and
| "pass through" all system calls to it except those systemd wanted
| to intercept. Which is kinda the opposite of what gVisor does!
|
| Some guy on a German Linux forum thought my idea was an actual
| plan by the systemd team, and another poster had to correct him
| that the author was "FAKE Lennart Poettering", so the joke either
| didn't land or landed all too well, depending on your
| perspective...
| _ananos_ wrote:
| well, jokes aside, what you're describing, is kind of what a
| "secure" (with many air/literal quotes) MCP/Agentic
| architecture looks like :D
|
| In this context we're experimenting with gvisor on various
| platforms, and we're preparing a demo for kubecon about a fine-
| grained sandboxing approach for AI agent tasks spawned from a
| sandboxed agent.
| tetris11 wrote:
| Is proot related to Gvisor?
| _ananos_ wrote:
| wasn't familiar with proot -- with a quick look I think proot
| is a fancy chroot -- which, in turn, is kind of "the first
| step" for a generic container.
|
| to achieve the isolation that gvisor offers you would have to
| intercept syscalls, create a separate mount/user/net namespace
| etc.
|
| regardless, I don't think proot is somehow related to gvisor ;)
___________________________________________________________________
(page generated 2026-03-13 23:01 UTC)