Five things have been going on in parallel for about a decade, and they get filed in five different drawers. Microkernels are an OS-research curiosity. eBPF is a networking tool. WebAssembly is a browser thing that escaped. LoRa mesh is for hikers. Confidential computing is a slide in a cloud vendor's deck.
Here at AxisOps we think they are all the same argument. Every one of them takes a position on a single question: where does the boundary go, and what does it cost to cross it?
That question is as old as the industry. What changed over the last ten years is that the answer stopped being "wherever the hardware happened to put it".
The boundary we inherited¶
For most of the industry's working life there were two boundaries worth the name, and the hardware chose both of them for us.
There's the process boundary, enforced by the MMU; one ring transition to cross, a page table per side, and a fault on one side doesn't take the other down with it. It's a good boundary and it's still doing most of the work in production today.
Then there's the machine boundary, enforced by a hypervisor. Much stronger, and much more expensive, because you're paying for a whole kernel per side.
Everything we built, we built by picking one of those two. Something that needed isolating got a process, or it got a VM. Think of it like a building where the only two options are a desk or a separate office block; most of the interesting failures of the last twenty years happened when neither size fitted, so nobody isolated anything at all.
Each of the five strands below is an attempt to build a boundary that the hardware never handed us.
1. Microkernels: the boundary moved down¶
The microkernel argument is old enough to have gone out of fashion twice. The architecture has not changed. What changed is that the proof turned up.
seL4's functional-correctness proof means something quite specific, and it's worth being careful here because it gets quoted loosely. The kernel's C implementation is proven to implement its abstract specification, with no unproven gap in between. That claim now holds across Arm 32-bit, AArch64, x86-64 and RISC-V 64-bit, and the AArch64 port has reached parity with the others on functional correctness (seL4 Summit 2024). The proof for the MCS configuration has since been completed on RISC-V (seL4 news).
The usual objection is IPC cost, and it's a fair objection; the cost is real. It's also the wrong place to stop the conversation, because what you're buying is a fault boundary around a driver, and a monolithic kernel can't sell you one of those at any price. A driver bug in Linux is a kernel bug. That is a structural problem, not a code quality one.
What a microkernel actually costs you has its own entry, which is honest about which numbers it still owes.
2. eBPF: the boundary became programmable¶
eBPF is the strand people underrate most, and we think that's because it turned up dressed as a networking tool.
The original extended-BPF patch landed in Linux 3.15: 64-bit registers, ten of
them rather than two, and an instruction set mapped closely enough to real
hardware to JIT. LWN reported it as "up to four times faster on x86-64" than
classic BPF on some network-filter microbenchmarks
(LWN, 2017). The bpf() system call that
exposed the VM to user space went up for review in July 2014
(LWN, 2014).
Described as a faster packet filter, that's a footnote. Described properly, it's the first time the Linux kernel took code from user space and ran it in kernel context on the strength of a proof.
The verifier is the whole story. It walks the control-flow graph depth-first to
establish that the program terminates and rejects unreachable instructions. Then
it simulates execution instruction by instruction, tracking register and stack
state and refusing out-of-bounds jumps, out-of-range access and reads of
uninitialised registers. In secure mode, for a loader without CAP_SYS_ADMIN,
pointer arithmetic is prohibited outright so that kernel addresses can't leak
(LWN, 2017).
So here's a boundary made out of static analysis rather than hardware. No ring transition, no page table, no context switch. You pay for the boundary once, at load time, in the verifier; after that the crossing is free, though the program still costs whatever its instructions and helper calls cost.
Kernel-side validation was not new: classic BPF had it, and proof-carrying code is older still. The scope was new, arbitrary programs against kernel data structures rather than packet filters.
3. WebAssembly: the boundary became portable¶
WASM is the same trick as eBPF, aimed at a different problem and approached from the opposite end. eBPF is a verified sandbox that got pushed down into the kernel. WASM is a verified sandbox that got pulled out of the browser.
Both of them give you a restricted instruction set, a validation pass that has to succeed before anything runs, linear memory the guest can't escape and no ambient authority; the guest gets the capabilities the host hands it and nothing more.
The capability model is the part we care about, and it's also where the reporting gets difficult. WASI's design is explicitly capability-based, so a module receives handles rather than a filesystem. The ecosystem timeline, though, is in a muddle, and most of what's written about it isn't reliable. We cover the component model separately in WASI: capabilities instead of containers, working from the specification and the Bytecode Alliance's own records rather than from secondary write-ups. A survey of the blog coverage gave us three contradictory dates for the same release. That's a comment on the state of the commentary, not on the technology.
What matters architecturally is that this boundary is portable. An eBPF program runs in a Linux kernel. A WASM module runs anywhere there's a runtime, with the same isolation properties, which makes it the first sandbox whose guarantees survive the trip between a server, an edge node and a browser tab.
4. Confidential computing: the boundary turned inwards¶
The three strands above all assume the host is trustworthy and the guest is suspect. Confidential computing turns that on its head and protects the guest from the host: memory encrypted with a key the hypervisor doesn't hold, and an attestation the workload can check before it will unseal anything.
This is the strand with the widest gap between the marketing and the engineering. The deployment reality has its own entry: what attestation really proves, what's inside the trusted computing base once you've counted the firmware and what encrypted memory costs you. Until we've measured it, treat anything here as a vendor claim.
It belongs on this list for a structural reason. It's the first of the five where crossing the boundary means proving who you are, rather than simply being permitted.
5. LoRa mesh: the boundary lost its centre¶
The odd one out, and the one that gets dismissed as a hobby more reliably than any of the others.
Meshtastic is LoRa radios running a mesh protocol with no infrastructure underneath: no base station, no carrier, no DNS, no CA. Nodes relay for each other, and the topology is whatever happens to be in range.
The engineering is a good deal more serious than "hikers with walkie-talkies" suggests, and the 2.8 firmware line is where you can see it. Packet signing via XEdDSA. Node IDs derived from a node's public-key identity rather than its hardware MAC address. A traffic-management module doing deduplication and rate limiting, and hop limits that vary with observed mesh activity (Meshtastic firmware releases, Meshtastic blog).
Read that list again as an identity architecture. A node is its key. There's no registry to ask because there's nothing to ask; authority lives in the keypair, so trust gets established peer to peer or not at all. The 2.7.15 release disallowed the legacy direct-message path, protected only by the shared channel key, after a spoofing advisory; DMs broke for nodes on older firmware while relaying and channels kept working. That's a compatibility break made for a security fix, in favour of the stronger property.
One note on currency, because it's the sort of thing a reader will check: the 2.8 line is alpha as we write this. 2.8.0 was revoked over a defect in the packet-signing code and replaced by 2.8.1, and the project's own advice is that most people should stay on 2.7 for the time being (Meshtastic blog). The stable base is 2.7; 2.8 is where the interesting protocol work is happening.
Same question as the other four, asked in a place with no centre at all: who is allowed to cross, and what proves it?
What actually led us here¶
Put the five side by side and the pattern is hard to miss.
| Strand | Boundary enforced by | Paid when | Protects |
|---|---|---|---|
| Process / MMU | Hardware page tables | Every crossing | Host from guest |
| Microkernel | Hardware + proof of the kernel | Every IPC | Everything from drivers |
| eBPF | Static analysis (verifier) | Once, at load | Kernel from user code |
| WASM | Validation + capabilities | Once, at validate | Host from module, portably |
| Confidential computing | Hardware + attestation | Continuously | Guest from host |
| LoRa mesh | Keypairs | Per packet | Peers from each other |
The direction of travel is consistent: away from boundaries the hardware chose for us, and towards boundaries we specify, verify and place where we want them. The cost model keeps shifting too, from per-crossing to paid-once-up-front, and that's what makes fine-grained isolation affordable for the first time.
That's why "security" is the wrong single label for any of this. Security is a consequence. What's being built is the ability to decide where a boundary goes, instead of accepting wherever the MMU put it in 1985.
The strand that explains the other five¶
One thing is missing from that table, and it's the thing that made all of it urgent.
In January 2018, Spectre and Meltdown made speculative execution everybody's problem. The hardware boundary, the one we'd all been treating as the solid floor underneath every design, turned out to leak across it by construction, in every high-performance processor shipped for twenty years.
Spectre did not start those five histories. It made their common boundary problem urgent and put them on the same table. Before it, "the MMU will handle it" was a perfectly reasonable engineering position. After it, all five strands above read differently; not as researchers being clever, but as five teams independently working out that a boundary you can't inspect is a boundary you can't rely on.
It has its own entry, because it deserves rather more than a paragraph.
What else belongs on this map¶
Five strands is the clean version of the story, and it's too clean. The fuller list of what's been worth watching since roughly 2012 is longer and messier: containers winning on ergonomics rather than isolation, the programmable dataplane, ARM reaching the server room, the storage hierarchy collapsing, Rust arriving in systems work, WireGuard, the supply chain turning into an attack surface and formal methods becoming practical. Most of it feeds one of the five.
Several of those have their own entries already, and they are the ones to read next if this map is useful: post-quantum migration, where key exchange is largely solved and certificates aren't; CHERI, putting bounds on pointers in silicon, the hardware answer to the problem eBPF and WASM solve in software; RISC-V reaching production; Rust arriving in systems work; energy as a design axis rather than an afterthought; and running inference on the bench rather than in somebody else's datacentre.
What is not covered here and should be: the supply chain as a first-class attack surface in its own right, and what happens to any of this when the verification key sits with somebody else.
Where we think this goes¶
The strands are converging rather than competing, and the interesting systems of the next few years will use several at once: a verified kernel hosting WASM workloads, attested, with eBPF doing the observability that a sandbox otherwise makes opaque. Each solves the granularity problem at a different altitude, and none is a general answer alone.
The part we would bet on is the cost model rather than any particular technology. Once you pay for a boundary at load time instead of at every crossing, the economics of "isolate this one function" change completely, and most of the architectural decisions the industry made under the old economics deserve another look.
What it buys everyone else¶
Cheap, fine-grained, verified boundaries are not an operating-systems hobby. They are the precondition for a handful of things people have wanted for years and could not afford:
A hospital analysing patient data on hardware it does not own, where the operator holds ciphertext and the privacy guarantee is arithmetic rather than a contract clause. A fifteen-year-old infusion pump getting a security patch, because a verified driver boundary means the vendor fixes one component instead of recertifying a whole device. A flood-warning mesh in a valley no telco will ever wire, running on nodes that hold their own keys and need no operator at all. An engineer running a capable model on the machine under their desk, where no prompt leaves the building. A small firm able to answer "what exactly is running on this box" with evidence.
Every one of those is a boundary problem dressed up as a policy problem. That is the argument for the whole decade of work above.
Who ends up holding the keys¶
The uncomfortable half, and the reason we bother writing any of this down.
A boundary is only as good as the key that attests it, and somebody holds that key. Attestation proves what is running to whoever holds the verification root, and today that root belongs to a silicon vendor. The cloud operator genuinely cannot read your memory; you have swapped trusting Amazon for trusting AMD. Better, and some distance short of ownership.
The same shape turns up at every layer of this map: the public registry everybody defaults to, the handful of certificate authorities, three clouds, two app stores, the model weights, the accelerators. A technology that could have gone either way acquires a chokepoint, and the chokepoint is where the rent gets collected and where the surveillance capability sits, whether or not anyone currently means to use it.
Worse, these primitives cut both ways by design. The attestation that proves to you that your workload is untampered proves to a platform that your device is unmodified, which is the mechanism behind locked bootloaders and signed-only firmware. That is a computer you own and cannot change, built from the tools these five strands spent a decade perfecting. The technology has no opinion.
Ours: we build infrastructure people can own, inspect and rebuild, and we are against the version of each technology above that works only while you keep paying for it. That preference is why a mesh node holding its own key gets a warmer write-up here than a cloud that will mind your secrets for a fee. The open, self-hostable version of most of this stack exists; some of it is keeping pace and some of it is quietly losing, and saying which is most of what this site is for.
Each strand has its own entry. This one is the map.