Hi, Matthias here - the person currently working on Jails for NetBSD, if one can call it that.

First of all, thank you for the lively discussion and all the feedback. I’ve been following the thread for a few days and I genuinely appreciate the input. Earlier today I also received a thoughtful email with some suggestions, which motivated me to respond here publicly as well.

To give a bit of background: the idea was indeed inspired by FreeBSD. I’m a long-time admirer of FreeBSD and have worked with it for many years. In my day job I mostly deal with Linux, Kubernetes, etc., while NetBSD has become the interesting counterpoint for me in my personal projects.

My original goal was actually to reproduce something quite close to FreeBSD jails. That’s also why you currently see aliases like jls and jexec in /etc/profile. But while learning the NetBSD internals and experimenting with prototypes, I realized that some of the defining properties of FreeBSD jails - particularly network isolation and strict resource controls in hot kernel paths - would require moving outside the relatively well-defined and safer territory of the secmodel framework. For a first kernel project, that started to feel like a risky direction.

At the same time, NetBSD already has a very elegant and robust answer for strong isolation of networking and resources like CPU and RAM: Xen. From a security perspective, that happens at a level where these concerns are naturally handled.

Because of that, the project gradually shifted. What currently exists (secmodel_jail) focuses more on controlled process isolation within the host rather than full virtualization-style containment. In parallel I’m already thinking about a concept where Xen VMs and these lighter-weight “jails” could be provisioned through a unified control plane, making the distinction transparent at the operational level.

Regarding the name: I completely understand the confusion.

When you picture a jail in the strict sense - a fully isolated cell with solid walls, a tiny window, and a food slot in the door - the current prototype is not quite that. What I built so far is closer to a cage: it prevents escape, but you can still reach through the bars. In practical terms, that means certain host resources remain shared, while the security model prevents destructive interactions (for example via signals).

That analogy is simplified, but it captures the spirit.

Because of this mismatch, I’m not opposed to renaming the project at this stage. Someone suggested “cages”, which actually fits the current design quite well. I’m also open to other ideas and might run a small poll once things settle a bit.

In any case, I just wanted to let you know that I’ve read the comments and appreciate the discussion. Feedback - critical or supportive - is very welcome, especially while the design is still evolving.

Thanks for the thoughtful conversation.

user:	mpeterma
created:	March 5, 2026
karma:	8