NetBSD Jails – Update: Ressourcenmodell, Netzwerkentscheidung und ein harter Freeze

Wo dieses Update einzuordnen ist

Wer den ersten Artikel gelesen hat, kennt bereits den Grundgedanken: secmodel_jail im Kernel erzwingt die eigentliche Identitäts- und Prozessisolation, jailctl steuert den direkten Lebenszyklus und jailmgr macht den Betrieb mehrerer Jails im Alltag handhabbar. Das zweite Update hat diesen Aufbau dann auf Architektur-Ebene vertieft, vor allem mit Blick auf Ressourcenmodell, Supervisor und mögliche NPF-Integration.

Dieses Update knüpft genau dort an. Es geht weniger um neue Features als um Entscheidungen unter Realbedingungen: Was funktioniert nicht nur konzeptionell, sondern auch unter Last? Welche Teile bleiben tragfähig, und was muss korrigiert werden, damit aus einem funktionalen Prototyp ein belastbarer Ansatz werden kann?

Der Ausgangspunkt: zwei offene Kernfragen

Seit dem letzten Architekturstand standen für mich zwei Fragen im Mittelpunkt. Erstens: Lässt sich eine tiefe Integration in UVM- und Scheduling-nahe Pfade stabil betreiben, um Speicher und CPU-Nutzung pro Jail wirklich deterministisch zu budgetieren? Zweitens: Ist eine Erweiterung der NPF-Syntax um ein jail-Attribut den Eingriff wert, um Regeln direkt an die Jail-Identität zu koppeln?

Beide Fragen greifen in Hot Paths ein, also genau in die Teile des Systems, in denen schon kleine Fehlannahmen große Folgen haben. Gleichzeitig bleibt mein Grundprinzip unverändert: kein virtueller Netzwerkstack, keine Network-Namespaces, kein Parallelbetrieb wie in einer separaten Containerwelt. Ich bleibe bei Host-Network innerhalb der Jails. Das ist bewusst eine klare Entscheidung für NetBSD-nahe Integration statt für eine zweite Runtime-Schicht.

Mehr Sichtbarkeit: neue Landing Page

Durch einen Mastodon-Post gab es in der vergangenen Woche deutlich mehr Rückmeldungen und Nachfragen als sonst. Deshalb habe ich eine kleine Landing Page gebaut.

ISO-Prototyp auf NetBSD 10.1: was sich geändert hat

Die verlinkte ISO auf Basis von NetBSD 10.1 (Branch netbsd-jails-v2) ist funktional vollständig, aber sie ist vor allem das Ergebnis mehrerer Korrekturen gegenüber früheren Annahmen.

Die wichtigste Korrektur betrifft RLIMIT. Im ersten Entwurf war das ein naheliegender Einstieg, weil RLIMIT im System vorhanden und gut verständlich ist. Im praktischen Jail-Betrieb zeigt sich aber schnell das strukturelle Problem: RLIMIT rechnet pro Prozess, während eine Jail fast immer eine Gruppe kooperierender Prozesse darstellt. Damit passt das Modell nicht zur eigentlichen Einheit, die wir isolieren wollen. Wenn man nur einzelne Prozesse begrenzen will, gibt es auf NetBSD bereits andere Wege. Für Jails braucht es gruppenbezogene Admission-Entscheidungen.

Deshalb ist die Ressourcensteuerung wieder eingeführt worden, diesmal über secmodel_eval. Die Idee dahinter ist bewusst sauber getrennt: Subsysteme treffen nicht selbst ad-hoc Limitentscheidungen, sondern delegieren sie an das Sicherheitsmodell. Ergänzt wurde das durch eine prototypische secmodel_setinfo-Schiene und Snapshot-basierte Aktualisierung der Jail-Ressourcendaten, damit secmodel_eval auf einer konsistenten Datenbasis entscheidet. Auf dem Papier ist das deutlich kohärenter als verteilte Speziallogik in mehreren Subsystemen.

Gleichzeitig wurde die geplante NPF-Syntaxerweiterung verworfen. Stattdessen ist die Netzseite jetzt klar auf kernelbasierte Port-Reservierung fokussiert. Das ist weniger invasiv, greift nicht in Parser und Paketpfad ein und liefert eine deterministische Bind-Semantik: Ein reservierter Port gehört zur richtigen jail_id, konkurrierende Binds aus anderen Domänen scheitern. Für exponierte Dienste ist das in der Praxis oft genau der robuste Kern, den man braucht.

Auch im Tooling gab es Fortschritt: Logging und Lifecycle in jailmgr sind konsistent, und jailctl kann Prometheus-Metriken direkt ausgeben, etwa über eine schlanke inetd-Anbindung. Damit bleibt Observability möglich, ohne eine zusätzliche Runtime-Schicht einzuziehen.

Der harte Rückschlag: reproduzierbarer Freeze

Der derzeit wichtigste Befund ist leider negativ, aber eindeutig: Unter gemischter hoher CPU- und I/O-Last lässt sich ein kompletter Freeze reproduzieren. Das System wird dabei nicht nur instabil, sondern steht vollständig still; Login, SSH und selbst der Kernel-Debugger sind in diesem Zustand nicht mehr erreichbar.

Aktuell spricht vieles dafür, dass die Ursache in secmodel_eval-Aufrufen aus Hot-Path-nahen Subsystemen liegt, insbesondere dort, wo Sperrreihenfolgen, Rekursion oder subtile Lock-Interaktionen zusammenkommen können. Genau das ist die unangenehme Realität solcher Integrationspunkte: Was architektonisch elegant aussieht, kann unter Last in eine harte Blockade kippen.

Konsequenz: NetBSD-11-Baseline ohne Ressourcen-Hooks

Parallel läuft bereits die Portierung auf NetBSD 11, das mit RC1 die neue Hauptbasis wird. Der Plan ist bewusst konservativ: Zunächst werden nur die stabilen Teile übernommen, also secmodel_jail, Tooling und Dokumentation. Die tiefe secmodel_eval-Verdrahtung in Subsysteme bleibt vorerst draußen.

Damit entsteht eine saubere Baseline, die sich auf das konzentriert, was schon heute belastbar ist: Identitätsisolation, kauth/secmodel-Integration und reproduzierbares Betriebsverhalten. Erst darauf aufbauend werden weitere Integrationen schrittweise wieder eingeschaltet und mit A/B-Messungen begleitet, um Overhead, Latenz und Durchsatz nicht nur zu vermuten, sondern sauber zu belegen.

Fazit

Dieses Update ist ein technischer Realitätscheck. Der Prototyp zeigt weiterhin klar, dass NetBSD-native Jail-Isolation mit secmodel_jail, jailctl und jailmgr funktioniert und praktisch nutzbar ist. Gleichzeitig ist jetzt ebenso klar, dass Ressourcensteuerung in Hot Paths eine andere Liga ist und nur mit sehr defensiver Integration tragfähig bleibt.

Genau deshalb verschiebt sich der Fokus: erst stabile Basis auf NetBSD 11, dann kontrollierte, messbare Erweiterung. So bleibt der Entwurf nachvollziehbar, und Fehler werden nicht kaschiert, sondern systematisch eingegrenzt.