Matthias Petermann

What about a nice Midnight Commander-style TUI to manage cells interactively? 🤔

https://netbsd-cells.petermann-digital.de

#netbsd #cellsfornetbsd #tui #devops #modernretrocomputing

Thanks everyone for the constructive discussion and participation in the naming poll over the past days. It was really helpful.

The former "Jails for NetBSD" project will move forward under the name "Cells for NetBSD".

New project page:
https://netbsd-cells.petermann-digital.de

Next steps will focus on stabilizing the current prototype, testing it with real-world workloads, and exploring further ideas around a NetBSD-native container technology.

#netbsd #freebsd

RE: @mpeterma@mastodon.bsd.cafe

Quick follow-up on the naming discussion around my NetBSD project (currently “Jails for NetBSD”):

I’m planning to close the poll tonight at midnight (2026-03-07 EST). That should give me the rest of the weekend to refactor the codebase for the new name and then continue with stabilization, review and new features.

If you haven’t voted yet, please do 🙂 Your input is very helpful.

I’ve been following the discussions about the name of my NetBSD project ("Jails for NetBSD") across a few platforms over the past days and really appreciate the thoughtful feedback.

The short version: the current prototype is probably closer to a cell or a cage than a strict jail, so the name might indeed not be perfect. The project originally started as an experiment inspired by FreeBSD jails, but while exploring NetBSD internals it evolved into something slightly different: controlled process isolation built around the secmodel framework, a different approach for the tool chain and configuration, and without resource limits and network virtualization.

Because of that, I’m open to renaming the project at this stage.

I’ve attached a small poll with a few candidate names — please vote if you like.
And if the right name isn’t listed yet, feel free to drop suggestions in the comments 🙂

Project site: https://netbsd-jails.petermann-digital.de/

#netbsd #jails #freebsd #openbsd

New checkpoint of the NetBSD jails prototype. Clean rebase on NetBSD 11 with no changes to existing upstream code except a bugfix. Also a new evaluation ISO based on NetBSD 11 RC1 (2026-03-05). Next experiments will explore non-user rlimits in the jail context and additional kauth gates (e.g. maxproc at fork).

https://netbsd-jails.petermann-digital.de

#netbsd

Since the last article, the secmodel_jail / jailctl / jailmgr stack has moved closer to a coherent whole. The original guardrails remain unchanged: no modifications to existing kernel paths, no UVM hooks, no NPF integration, no hidden coupling. The scope stays explicit and the risk bounded.

Progress has focused on operations. Logging, lightweight supervision, and basic metrics are in place, shifting the question from "can this work?" to "can this be run?". Networking remains intentionally simple and host-based; for hard isolation, Xen is still the right boundary. Jails provide an operational frame inside the host, not a replacement for virtualization.

Resource budgeting is being prototyped again via the secmodel evaluation interface, touching allocation paths and scheduler run queues in a minimally invasive way, but it needs careful review.

There is now also a small landing page to make the ideas visible, including an experimental amd64 ISO based on NetBSD 10.1 for testing. If it sparks upstream interest or discussion around lightweight, explicit isolation on NetBSD, that is already a win.

https://netbsd-jails.petermann-digital.de/

#netbsd

While writing my article, it became clear to me how much responsibility — and especially experience — is required to touch areas like UVM or NPF inside NetBSD.

I’ve learned a lot over the past weeks. But I’m also honest enough to say: I don’t yet have the depth of experience needed to modify those subsystems responsibly.

So I made a conscious decision.

I’ve created a new experimental branch for secmodel_jail / jailctl / jailmgr that is strictly additive:

- No changes to existing kernel code paths

- No UVM hooks

- No NPF integration

- No hidden coupling between subsystems

It adds new code only.

The reason is simple: even without deep UVM or NPF integration, the security model already delivers significant practical value for me. And in this reduced, explicit form, the attack surface is clear and the audit scope sharply defined.

This feels like the right first alpha candidate: understandable, bounded, and reversible.

https://github.com/MatthiasPetermann/netbsd-src/tree/feature/jails-v1-ga

#netbsd