Flagship · ParanoidBSD

An operating system where authority is held, not assumed

Nearly every break-in works the same way: a program reaches something it was never meant to touch. ParanoidBSD is an operating system built so that it cannot. Each program is handed only what it needs, and everything else is not merely forbidden — it is out of reach. Built on HardenedBSD, rewritten in modern C++, with the original kept alongside so every change can be checked against it.

LanguageC / C++23
BaseHardenedBSD 15-STABLE
DesktopKDE Plasma 6
Last pushrecently
Stars—
Repository layout
pbsd/C++23 modules — kernel nucleus, userland ports, UDA, BIFROST, compositor, theme
hbsd/HardenedBSD 15-STABLE source — the original, kept as the spec
kde/Plasma 6, KWin and frameworks for the desktop wave
tools/Inventory, deterministic rewrite passes, agent port, Clang helpers
docs/Specs, security model, migration status, provenance
scripts/Windows Subsystem for Linux (WSL) driver script, watchdog, progress console
In plain English

What this is, in one minute

The problem

An operating system sits underneath everything else an organisation runs. Most are built on decades of older code, and they let any program ask for anything at all — the system decides afterwards whether to allow it. That is why one flaw in something harmless, like the code that draws a font on screen, can end with stolen passwords.

The solution

ParanoidBSD changes what a program is able to ask for in the first place. Rather than checking permission after the request, it hands each program a short list of things it may touch, and gives it no way to name anything else. A flaw in one part stops being a route into the rest.

Who it is for

Defence and government suppliers now being asked for software written in safer languages. Equipment that stays in the field for years and cannot be patched quickly — factory controllers, medical machines, utility hardware. Teachers and researchers who want a real operating system small enough to read end to end.

Security should not start at the application layer. It should start with the operating system underneath it. The rest of this page is the engineering: what was changed, how it was checked, and what is not done yet.
The problem

Ambient authority is the bug you cannot patch

On a conventional Unix, a process does not hold the right to open /etc/master.passwd. It simply asks, and the kernel decides afterwards, based on who the process claims to be. Every process can name every resource on the system. The name space is global and ambient; the check is a late afterthought.

That is why a single parsing bug in a font renderer can become a credential theft. The renderer never needed the password file — but nothing in the architecture stopped it from asking.

HardenedBSD already does serious work here: Address Space Layout Randomisation (ASLR), which loads a program somewhere different every time so an attacker cannot guess where anything is; Control Flow Integrity (CFI), which stops a program being steered into code it was never built to run; and PaX-derived mitigations, SafeStack and hardened memory allocators alongside them. PBSD keeps all of it and changes the shape of the question underneath — from “is this process allowed?” to “does this process hold a handle to that?”

Two ways to answer one syscall

// Ambient authority — the traditional path
int fd = open("/etc/master.passwd", O_RDONLY);
// kernel walks a global namespace, then
// checks uid/gid/MAC after the fact

// Handle nucleus — the PBSD path
auto f = dir_handle.open("master.passwd", Rights::Read);
// there is no global namespace to walk.
// no handle, no name, no operation.

Illustrative shape of the difference, not a verbatim listing of the calls a program makes into the kernel — its Application Programming Interface, or API. The authoritative model is in docs/.

Two authority models compared side by side: under ambient authority the process reaches sockets, exec and ptrace and is refused the password file only after asking; under the handle nucleus only the resource it holds a handle to can be named at all
scroll to see the whole diagram →
Where the check happens. On the left the request always travels and is judged afterwards. On the right, three of the four operations have no name to ask with, so there is nothing to refuse.
Interactive

Walk a syscall through the nucleus

Give the process some handles, pick something for it to attempt, and switch between the two authority models. The verdict and the reasoning are computed live in your browser — this is a teaching model of the design, not a kernel emulator.

Capability nucleus — reference monitor

The process attempts…

Trace

Handles held by the process

Verdict

Awaiting attempt
Pick an operation to run it through the monitor.
Reachable
0
Denied
0

“Reachable” counts how many of the listed operations this process could perform at all under the current model. Under ambient authority, reachability is decided by identity; under the nucleus, by the handles it actually holds.

A pedagogical model of the PBSD security design, written for this page. The real nucleus lives in pbsd/; the specification is in docs/specs/.
The port

Four stages, and a model that never certifies itself

Porting a Berkeley Software Distribution (BSD) userland and kernel to C++23 by hand is a decade of work. Porting it by asking a language model to rewrite files is a fast way to produce plausible garbage. PBSD does neither.

The ParanoidBSD port pipeline: inventory, deterministic passes, agent loop and a verification gate, with rejected files looping back
scroll to see the whole diagram →
How a file becomes a ported file. The dashed red path is the part that matters — work that fails verification goes back into the loop rather than counting as progress.
Stage 1

Inventory

tools/inventory_c_sources.py and clang_cxx23_port.py score every C file by difficulty and write c_inventory.csv. Nothing is guessed about scope.

Stage 2

Deterministic passes

run_todo_passes.py applies safe mechanical rewrites in tiers 0–4. No model involved. Anything a pass refuses is logged to refusals.jsonl rather than forced.

Stage 3

Agent loop

pbsd.py fills stubbed and refused files with DeepSeek Flash escalating to Pro at maximum reasoning effort — 48 Flash and 24 Pro workers by default. This is what the Kickstarter funds.

Stage 4

Verification gate

Compile, ASan, UBSan, differential execution and comparison at the level of the compiler’s Intermediate Representation (IR). A file that only compiles is unverified. Failures land in agent_port_failures.jsonl.

The BSD daemon shown twice: on the left the original red mascot, on the right the same figure rendered as a cyan wireframe, with an equals sign between them
The project in one picture. Same daemon, same shape, rebuilt in a different representation — and the equals sign is the part that has to be earned, file by file, by differential verification. BSD Daemon © Marshall Kirk McKusick.
What “equals” has to mean

A port is a claim of equivalence

Saying a file has been ported is saying the new one behaves like the old one. That is a claim, and claims need evidence. A C++23 rewrite that compiles is a plausible-looking wireframe; it is not yet the same daemon.

So the equals sign is the gate. Differential execution runs both and compares observable behaviour. IR comparison checks they mean the same thing to the compiler. Until one of those passes, the file stays open in the migration log and does not count toward progress — however finished it looks.

The rule that makes this defensible: the model does not self-certify. It proposes; deterministic tooling disposes. Every non-negotiable in the repository exists to keep that boundary intact — which is also why the port cannot simply be run faster by spending more on inference alone.
Non-negotiables

Rules the repository is actually held to

No file is done until differential or IR verification passes
Compile-only is treated as unverified. A ported file must either produce identical observable behaviour to the HardenedBSD original under differential execution, or match at the IR level. Files that pass neither stay open in the migration log and are not counted in progress figures.
Port faithfully — do not silently “fix” bugs in the original
The HardenedBSD tree is the behavioural specification. If the original has a defect, the port reproduces it, because a differential test cannot distinguish a fix from a regression. Improvements are made afterwards, logged separately, so the change is visible and reviewable rather than buried inside a translation.
Deterministic tooling first; models fill only what remains
Mechanical rewrites are applied by scripts that behave identically every run. Models are used exclusively on the residue — stubbed inventory entries and files the deterministic passes refused. This keeps the majority of the port reproducible and auditable, and confines model output to the parts a human would have had to write by hand anyway.
Kernel C++ is freestanding: -fno-exceptions -fno-rtti
The kernel nucleus cannot depend on a hosted C++ runtime. No exceptions, no Run-Time Type Information (RTTI), no heap-allocating standard library paths on kernel entry. The constraints are written down in docs/specs/KERNEL_CXX_ABI.md so that a contributor can tell what is legal in kernel context without guessing.
Every module needs a provenance entry before it counts as done
docs/PROVENANCE.md records where each module came from and under which licence. This is what makes the licensing statement below verifiable rather than aspirational — you can check, module by module, which code is HardenedBSD-derived and which is new PBSD work.
Licensing

Two licences, honestly separated

New PBSD code — the nucleus, the C++23 modules, the tooling — is offered under Imortek’s standard terms: the GNU Affero General Public License (AGPL-3.0+), free for personal use, charities, education and organisations under 50,000 Australian dollars (AUD) a year, with a tiered commercial licence above that.

Code derived from HardenedBSD stays under its original BSD licence. It cannot be relicensed and Imortek does not claim to. docs/PROVENANCE.md is the record of which is which.

Full licensing terms →
AGPL-3.0+ & commercial

New PBSD work

pbsd/, tools/, scripts/, the capability nucleus, UDA, BIFROST, compositor and theme.

BSD (unchanged)

HardenedBSD-derived

hbsd/ and every ported file tracing back to it. Original terms, original attribution.

Who it is for

An operating system that is harder to break into

Most break-ins exploit the same kind of mistake: a program reaching memory it was never meant to touch. ParanoidBSD rebuilds a trusted system in a language that makes that mistake much harder, and hands every program only the access it actually needs.

01

Defence and government suppliers

Buyers are starting to insist on software built in languages that shut out whole classes of attack. Starting again from nothing costs a decade. This moves a proven system across instead, and keeps a written record of every file it changed and how that change was checked.

02

Equipment that stays in the field for years

Factory controllers, medical machines, utility hardware. When a flaw turns up you often cannot just push an update. This limits how far an intruder gets once they are in, because no program can reach past what it was handed.

03

Universities and security researchers

A real operating system, small enough to read end to end, with the original sitting beside it to compare against. Useful for teaching and for testing ideas on something that actually runs.

Recognise your situation here? This is open for beta testing now, and the people it is built for are the ones whose feedback actually changes it. Become a beta tester →
Kickstarter live · closes 12 November 2026

The port runs on compute it does not have

Deterministic passes are free. The agent loop that fills the residue — and the verification runs that gate it — are not. That is the entire ask.