2026-07-13·10 min read·sota.io team

Deploy seL4 to Europe — Gerwin Klein 🇩🇪 + June Andronick 🇫🇷 + NICTA (2009), the World's First Formally Verified OS Microkernel, on EU Infrastructure in 2026

Every operating system kernel sits at the boundary where software makes promises it cannot prove. A kernel handles context switches, memory mapping, inter-process communication, interrupt handling, and access control — operations that, if implemented incorrectly, allow one process to corrupt another, read another's memory, or escalate privileges beyond what the system was designed to permit. Modern kernels are tested extensively, reviewed carefully, and audited regularly. None of that makes them formally correct: it makes them well-tested, which is not the same thing.

seL4 is different. Created in 2009 at NICTA (National ICT Australia, now Data61/CSIRO) by Gerwin Klein 🇩🇪, June Andronick 🇫🇷, Kevin Elphinstone, and collaborators, seL4 is the world's first operating system kernel whose correctness is formally proved in a machine-checked proof assistant. The Isabelle/HOL proof — approximately 500,000 lines — establishes that seL4's C implementation faithfully implements its abstract functional specification, that isolation between processes is never violated, and that information cannot flow from a high-security component to a low-security one without passing through the kernel's enforced interfaces.

In 2026, with the EU Cyber Resilience Act requiring formal evidence of security properties for connected products, and EU AI Act Article 9 demanding systematic verification for high-risk AI systems, seL4's proved isolation guarantees are exactly what EU defence, aerospace, and critical infrastructure organisations need. Deploying seL4-based workloads on EU infrastructure keeps all cryptographic keys, system configuration, and audit artefacts under EU jurisdiction — a requirement for Hensoldt's classified German defence programmes and an expectation for AI Act Annex III operators.

What seL4 Proves

The seL4 proof comprises three distinct but interdependent theorems, each proved in Isabelle/HOL (Lawrence Paulson 🇬🇧, University of Cambridge, 1988 — covered in the Isabelle blog post in this series):

Functional correctness. The C implementation of seL4 refines the abstract functional specification. Every system call, IPC operation, capability manipulation, and scheduler action in the C code produces exactly the state transitions described in the high-level model. This is proved by first abstracting the C source to a Haskell-style functional model (via AutoCorres, a C-to-Isabelle translation tool) and then proving refinement between that model and the abstract spec.

Integrity (spatial isolation). A subject (process or thread) can only read and write memory and kernel objects it holds the appropriate capabilities for. Capability transfer is the only legitimate mechanism by which access rights can be propagated. The proof establishes that no subject can corrupt another's address space, invoke another's endpoints, or access kernel data structures without a valid capability chain. No buffer overflow, no speculative-execution side channel, no confused-deputy attack can violate this — if the property holds, it holds for all possible programs, including malicious ones.

Confidentiality (information-flow security). The seL4 information-flow proof (Mutual Noninterference) establishes that high-security subjects cannot leak information to low-security subjects through any sequence of kernel operations. This is the strongest security property a kernel can offer: it rules out covert channels through timing, cache behaviour, and shared-resource contention at the kernel interface level.

These three proofs compose. Taken together, they establish that seL4 enforces its security policy — isolation between components — against all code running on the system, including buggy drivers, malicious applications, and compromised VMs.

Gerwin Klein and June Andronick

Gerwin Klein 🇩🇪 (born in Germany, educated at TU Munich 🇩🇪 — the institution also home to Tobias Nipkow's Isabelle/HOL group) led the seL4 verification project at NICTA from 2004 to 2009. The SOSP 2009 paper "seL4: Formal Verification of an OS Kernel" won the ACM SIGOPS Hall of Fame Award (retrospectively, for lasting impact) and the ASPLOS 2018 Influential Paper Award. Klein is now co-founder of Proofcraft, a company commercialising the seL4 proof and its extensions.

June Andronick 🇫🇷 is a French researcher who joined the seL4 verification team at NICTA (later Data61) and has been a principal contributor to the extended proofs, including the information-flow theorem and the ongoing binary verification work. Andronick studied in France and brings the French formal methods tradition — the Coq/Why3/INRIA cluster — into dialogue with the Isabelle/HOL school. She is now also at Proofcraft.

The seL4 core verification team combined German precision (Klein's TU Munich background, Isabelle's Nipkow connection), French formal methods rigour (Andronick, AutoCorres contributions from INRIA-adjacent researchers), and Australian systems engineering pragmatism — a genuinely international EU-adjacent research collaboration that produced the world's most verified software artefact.

The Isabelle/HOL Proof Stack

The seL4 proof is the largest single Isabelle/HOL verification in existence. Its structure:

Abstract Specification (Isabelle/HOL functional model)
    ↑ Refinement proof (Klein + Andronick et al., ~200k LOC Isabelle)
Executable Specification (Haskell-style functional model, prototype implementation)
    ↑ Refinement proof (~100k LOC Isabelle)
C Implementation (seL4 kernel, ~10k LOC C)
    ↑ AutoCorres (C-to-Isabelle translation, Tobias Nipkow's group, TU Munich 🇩🇪)
Isabelle/HOL representation of C semantics
    ↑ Integrity + Confidentiality proofs (~150k LOC Isabelle)
Security properties (Mutual Noninterference)

AutoCorres (the C-to-Isabelle translation tool used by seL4) was developed at NICTA and is now maintained as open-source. It provides a mechanically verified translation of ANSI C code to Isabelle/HOL terms, making the C semantics gap — the same gap that CompCert closes for compilation — tractable for verification.

The proof is checked by Isabelle/HOL, which in turn is proved sound against a small trusted kernel (the Isabelle meta-logic). The trusted computing base of the entire seL4 verification is: the Isabelle meta-logic (a few hundred lines of ML), the AutoCorres translation, and the hardware model of the target processor.

EU Industrial Deployment: Hensoldt, Airbus, TRENTOS

Hensoldt Cyber GmbH 🇩🇪 (Taufkirchen, Bavaria — a subsidiary of Hensoldt AG, Germany's leading defence electronics company, headquartered in Taufkirchen near Munich) has built TRENTOS — a secure operating system for embedded defence systems — directly on top of seL4. TRENTOS uses seL4's capability-based isolation to separate classified and unclassified software components running on the same processor, with formal proof that the separation holds. Hensoldt's customers include the German Bundeswehr and EU NATO partners.

TRENTOS represents the first mass-production use of a formally verified OS in European defence electronics. The verification certificate for seL4's isolation properties is part of the product's formal safety case — a direct artefact of the Isabelle/HOL proof, presented to German defence procurement authorities (BWB) as assurance evidence.

Airbus Defence & Space 🇩🇪🇫🇷 (Toulouse and Munich) has evaluated seL4 for next-generation avionics and space systems where DO-178C Level A is required and current RTOS products (VxWorks, LynxOS) provide no formal proof. The combination of seL4's isolation proof with CompCert's compiler proof and Frama-C's source verification creates a fully formally verified stack from application source code to running binary — with no unproved gap at the OS or compiler layer.

The European Space Agency 🇪🇺 (ESTEC, Noordwijk 🇳🇱) has funded seL4 evaluation for LEON-based space platforms (the same processor family where CompCert and SPARK Ada are deployed), seeking formally proved isolation for multi-domain spacecraft software where a single radiation-induced error in a non-critical application must not corrupt flight-critical functions.

EU Regulatory Context: CRA 2027, NIS2, EU AI Act

Cyber Resilience Act (CRA, 2027). The CRA requires manufacturers of products with digital elements to demonstrate security properties including isolation between security domains, absence of known vulnerability classes, and secure update mechanisms. seL4's capability-based isolation — formally proved — is the strongest available technical evidence that a product's security architecture prevents privilege escalation and cross-domain contamination. CRA Article 13(2)(a) requires "appropriate security measures" for the product's architecture: seL4's proof provides the highest attainable assurance level for OS-layer isolation.

NIS2 Directive. For operators of essential services (energy, transport, water, digital infrastructure), NIS2 requires appropriate technical measures to manage cybersecurity risk. seL4-based systems running on EU infrastructure separate safety-critical control logic from external-facing network code with formal proof — exactly the architectural separation NIS2 expects without specifying how.

EU AI Act Article 9. High-risk AI systems (Annex III: autonomous vehicles, medical devices, critical infrastructure, biometric identification) require systematic risk management. For AI systems where the inference engine runs on a shared platform alongside non-AI code, seL4's proved isolation prevents compromised non-AI components from accessing AI model weights, sensor inputs, or actuator outputs. The isolation proof is machine-readable, tool-generated assurance evidence acceptable under ISO/IEC 25010 and directly relevant to Art. 9 technical documentation.

seL4 Architecture: Capabilities and Minimal TCB

seL4 follows the microkernel philosophy: the kernel does the minimum necessary to enforce isolation, and everything else — device drivers, file systems, network stacks, even memory allocators — runs in user space. The kernel provides:

Capability-based access control: every object (memory frame, IPC endpoint, thread, notification) is accessed via a capability stored in the thread's capability space (CSpace). A thread can only access objects for which it holds a valid capability. The kernel enforces this at every system call boundary.
Synchronous IPC via endpoints: threads communicate by passing messages through endpoint capabilities. The kernel enforces that only threads holding send/receive capabilities can participate in each communication channel.
Virtual memory management via page-table objects: threads map memory by invoking capabilities on page-table objects. The kernel never maps memory without explicit capability authorisation.
Untyped memory capabilities: the only way to create new kernel objects is via an untyped capability — a reference to unallocated physical memory. The root task (the first userspace process) holds all untyped capabilities and delegates them down to subsystems. Object creation is capability-controlled and tree-structured.

This minimal interface is what makes the proof tractable: there are only a few dozen system calls, each with a precisely specified effect on the capability state. The proof covers all of them.

/* seL4 system call: send a message via an endpoint capability */
seL4_Send(seL4_CPtr ep_cap, seL4_MessageInfo_t msgInfo);

/* seL4 system call: receive a message from an endpoint */
seL4_Recv(seL4_CPtr ep_cap, seL4_Word *sender_badge);

/* seL4 system call: invoke a capability on a kernel object (e.g., map a page) */
seL4_Untyped_Retype(seL4_CPtr untyped, seL4_ObjectType type,
                    seL4_Word size_bits, seL4_CPtr root,
                    seL4_Word node_index, seL4_Word node_depth,
                    seL4_Word node_offset, seL4_Word num_objects);

The CAMKES component framework (developed at TU Munich 🇩🇪 / NICTA) builds higher-level component composition on top of seL4's primitive IPC, generating capability wiring and endpoint configurations from component interface definitions — enabling architects to reason about system composition without manually specifying capability graphs.

Deploying seL4-Based Systems on sota.io

sota.io is a European PaaS — infrastructure in EU data centres, GDPR-compliant, managed PostgreSQL, zero DevOps, free tier.

seL4 itself runs on bare metal or in a VM (QEMU for development, hardware for production). For development workflows — cross-compilation, QEMU simulation, proof checking — sota.io's Linux containers are the appropriate deployment target:

# Install seL4 build dependencies (Ubuntu 22.04)
apt-get install -y python3 python3-pip cmake ninja-build gcc-aarch64-linux-gnu \
    gcc-arm-linux-gnueabihf qemu-system-arm qemu-system-x86 \
    libxml2-utils libssl-dev

# Install sel4 Python tools
pip3 install sel4-deps

# Clone seL4 kernel
git clone https://github.com/seL4/seL4.git
git clone https://github.com/seL4/seL4-CAmkES-L4v-dockerfiles.git

# Build seL4 for x86-64 with verification configuration
mkdir build && cd build
cmake -DCROSS_COMPILER_PREFIX= -DCMAKE_TOOLCHAIN_FILE=../kernel/gcc.cmake \
      -DKernelPlatform=x86_64 -DKernelVerificationBuild=ON ..
ninja all

# Run in QEMU
qemu-system-x86_64 -kernel images/kernel-x86_64-pc99 \
    -initrd images/capdl-loader-image-x86_64-pc99 \
    -nographic -m 512

# Dockerfile: seL4 cross-compilation environment on sota.io
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y \
    python3 python3-pip cmake ninja-build \
    gcc-aarch64-linux-gnu gcc-arm-linux-gnueabihf \
    qemu-system-arm qemu-system-x86 \
    libxml2-utils libssl-dev git
RUN pip3 install sel4-deps
WORKDIR /workspace
CMD ["bash"]

For the Isabelle/HOL proof verification (checking the seL4 proofs from source), a Pro tier instance (4 GB RAM, 4 vCPU) is recommended — proof checking the full 500k-line corpus requires several hours of compute. This is typically run once per kernel release to confirm the proof still holds against the updated C source.

The seL4 Foundation and EU Membership

The seL4 Foundation (founded 2020, hosted under the Linux Foundation) governs seL4's open-source development and maintains the proof. EU members of the seL4 ecosystem:

Hensoldt Cyber 🇩🇪 (TRENTOS, defence) — founding industrial member
Airbus Defence & Space 🇩🇪🇫🇷 (aerospace evaluation)
Critical Systems Labs (EU aerospace clients)
Proofcraft (Gerwin Klein 🇩🇪 + June Andronick 🇫🇷 — commercial verification and proof maintenance)
TU Munich 🇩🇪 (Tobias Nipkow's group, Isabelle/HOL, CAMKES)

The foundation's charter ensures seL4 remains open-source (GPL-2 kernel, BSD userland) with the Isabelle/HOL proof publicly available. No single US company controls the seL4 roadmap — a significant distinction from proprietary RTOS products (Wind River VxWorks, Green Hills INTEGRITY) that dominate current safety-critical markets.