The NoWayOS Journal

React in, Rust out

2026-11-13T00:00:00Z

Modern interfaces are designed in React. So a great many dedicated devices, from control panels to ticket machines, ship a whole browser engine, one of the largest and most attacked programs there is, to draw a few buttons and the words "Touch Start to begin".

We wanted the modern design workflow without the browser. So we built the Screen Compiler.

Write the screen in React

Your designers and front-end developers keep their tools: components, props, design tokens, their editor. They write the screen in TSX (this one is shortened from one of the Screen Compiler's test screens):

<Column gap={SPACE_SM} padding={SPACE_LG}>
  <Text id="title">Welcome</Text>
  <Text>Touch Start to begin.</Text>
  <Spacer />
  <Button id="start" onPress={onStart}>Start</Button>
</Column>

Ship plain Rust

At build time, on your machine or in CI, the Screen Compiler turns that into Rust for NoWayOS's user interface runtime:

let n1 = b.text("Welcome")?; // welcome.tsx:17:9 <Text>
let n2 = b.text("Touch Start to begin.")?; // welcome.tsx:18:9 <Text>
let n4 = b.spacer(None)?; // welcome.tsx:20:9 <Spacer>
let n5 = b.button("Start", actions::START)?; // welcome.tsx:21:9 <Button>

Every line points back to the TSX it came from. The device gets that code and nothing else: no JavaScript engine, no browser, no web page to attack. The Screen Compiler itself never ships.

Exact, or nothing

A converter that guesses is a converter you can't trust. The Screen Compiler converts its declared subset of TSX exactly, and refuses everything else with the file, line and column. It never approximates. The Rust it writes has no unsafe, no unwrap and no panic.

Then every converted screen is drawn by NoWayOS's renderer and compared, pixel for pixel, with its approved image. If a single pixel moves, the build says so.

Where it stands

The Screen Compiler is in development: its first subset is built and the next is under way. It's open source under MIT, on GitHub beside NoWayOS. If your team designs in React and builds devices that matter, we'd like to hear from you.

The backup that wasn't a copy

2026-11-13T00:00:00Z

Everybody knows you should have a backup. Fewer people ask the awkward follow-up: a backup of what, exactly?

Five alarms

On 20 July 1969, Apollo 11's lunar module was a few minutes from the surface of the Moon when its guidance computer raised an alarm the crew had to ask Mission Control about. Then another. Five in all, in the last stretch of the descent.

The computer was overloaded. What it did next is one of the great pieces of engineering in the story: each time, it restarted, dropped the work that could wait and picked the work that couldn't straight back up. The landing went on.

That's the part everyone tells. The part worth telling next happened the following day.

The second system

The lunar module carried a second guidance system, and it was not a spare copy of the first. A different company built it, on a different principle. The main system kept its bearings with a platform that swung freely on gimbals. The second had no gimbals at all: its sensors were bolted straight to the spacecraft, and it worked out which way was up by arithmetic.

It was there to fly the crew back to orbit if the main system ever stopped. During the landing it wasn't called on.

Then, on the way back up to dock with the command module, a run of manoeuvres took the main system's platform into the one position a gimballed platform can't cope with, and it lost its attitude reference. The crew switched to the second system to hold the spacecraft steady, and docked.

The second system could not have failed the same way. It didn't have the part.

Two of the same

Now the other story. In 1996 the first Ariane 5 lifted off with two inertial reference units to tell it which way it was pointing: one working, one standing by. They were identical, down to the software.

Thirty-seven seconds in, a number inside that software grew too large for the space set aside for it. The stand-by unit stopped. The working unit, running the same code on the same flight, stopped as well. The inquiry's report is public, and it is blunt: there was nothing to switch to, because the backup had already gone the same way.

Two copies. One fault. Nothing left.

What engineers call it

A fault that takes out a system and its spare together is a common-cause failure. The defence against it is diverse redundancy: a second system built differently enough that what stops the first isn't in the second.

The Space Shuttle flew this way. Four of its flight computers ran one company's software; the fifth ran software written separately by another. Four copies protect you from a computer that breaks. They don't protect you from a program that's wrong, because all four are running it.

It isn't free. The Shuttle's first launch was called off when the fifth computer and the other four couldn't agree on the time. Two designs are more work than one, and they have to be made to meet.

Where NoWayOS comes in

Most dedicated devices today run one of a very small number of general-purpose operating systems. So do their backups. When a flaw turns up in a browser engine, a desktop or a kernel of tens of millions of lines, or when a bad update goes out, it turns up everywhere that software runs, on the same day.

A NoWayOS device is different underneath. Its kernel is seL4, about 10,000 lines. Everything of ours above it is written in Rust. It has no browser engine, no desktop and no shell, so a flaw in one of those is not in it.

That means NoWayOS doesn't have to replace what you run to be useful. It can stand beside it: a second way to do one essential job, built on a different principle.

What it doesn't do

Diversity has limits, and we'd rather you heard them from us.

It gives a NoWayOS device different faults, not none. It does nothing for what two systems share: the power, the network, the services behind them, or a mistake in what the job was meant to be. And some of NoWayOS's open-source parts are used in other software too, which is why every image lists every component it contains, so you can read what it has in common with the system next to it.

NoWayOS is in development, so this is a role it is designed for, not one it has filled yet. The Security page says what it rests on.

Apollo's engineers didn't carry a second system because they expected the first to fail. They carried it because they couldn't prove it wouldn't, and they made sure that whatever stopped the first would find nothing familiar in the second.

We attack our own build on every change

2026-11-13T00:00:00Z

Here's an uncomfortable question for any security test: has it ever failed? A test that has never failed might be passing because the system is sound, or because the test can't see anything at all. From the outside, the two look exactly the same.

So NoWayOS doesn't just test its security. It attacks it, on every change, and checks that the attacks are caught.

Reaching for what isn't yours

Each part of a NoWayOS system runs in its own compartment on seL4, holding only what it was granted. The isolation tests send probes across those boundaries on purpose. One reads an address it was never given. One writes to a page it may only read. One, holding exactly what the user interface holds, tries to write the display's control page, which the interface may only read. Another, holding exactly what the network client holds, tries to write into the network driver's memory.

seL4 must stop every one of them, and a bystander part must carry on running, untouched.

A test built to fail

Then comes the twist. Beside the user interface's isolation test sits a variant with one grant widened on purpose: the interface's stand-in is given the display's private page. That variant's test must fail. If it ever passed, the isolation test would be blind, and the build would say so.

The same idea runs through the rest of the checks. Every decoder of messages between parts has bounded proofs, from the Kani model checker, that it never panics, overflows or reads out of bounds. Mutation checks then break the decoders deliberately, to show the proofs notice. Every parser of outside input is fuzzed with hostile data.

All of it is part of make ci, the gate every change must pass. The isolation tests run every time; a proof or a fuzz run is repeated whenever the code it covers changes.

Gates out of reach

A gate is only as strong as the hand that can change it. So the checks every contribution to NoWayOS must pass are defined in Defence Agent, a public repository of their own. A pull request that touches a gate is flagged for the maintainer.

Defence Agent tests itself the same way: twenty planted pull requests, each hiding something a reviewer could miss. There's hidden right-to-left text in a comment, a letter swapped for its Cyrillic look-alike, a dependency fetched straight from a git repository, a workflow that would run untrusted code. Each must be caught, while three real past changes must pass.

Proof, not adjectives

None of this makes a device “unhackable”. Nothing does, and we'll never say it. What it gives you is evidence: a record of what was tried, what was stopped, and the command that shows it. Read one real image's evidence, or the gates themselves.

What a proof can promise

2026-11-13T00:00:00Z

Software is usually trusted because it was tested. Somebody thought of the ways it might go wrong, tried them, and watched it cope. That works well, right up to the case nobody thought of.

A proof starts from the other end. It doesn't try cases. It shows, by mathematics, that a statement holds for all of them.

Every case, not the ones we tried

Take a small promise: this code never reads past the end of its buffer. A test can feed it a thousand inputs, or a billion, and report that none of them broke it. A proof says something of a different kind: there is no input that breaks it. Not one was found, and not one exists.

The price is rigour. A proof needs an exact statement of what the code should do, called its specification, and an argument that connects every line of the code to it. For real software that argument is far too long for a person to check by eye. So a computer checks it.

Checked by machine

That is what “machine-checked” means. The proof is written out in full, in a language a program called a proof assistant can read, and the program checks each step against the rules of logic. It doesn't get tired on page nine hundred, and it doesn't take anyone's word for anything.

seL4's proofs are checked this way, in a proof assistant called Isabelle/HOL. They are public, and anyone can run them again.

What seL4's proofs say

seL4 is the kernel every NoWayOS system runs on: about 10,000 lines of code, and the only code with total control of the device. Its size is the point. An argument about ten thousand lines can be finished. An argument about tens of millions cannot, not yet.

The seL4 Foundation sets the proofs out in layers:

The code does what the specification says, and nothing more. From that follows a list of things the kernel cannot do: overrun a buffer, follow a null pointer, leak memory, divide by zero.
The program that runs matches the code that was proved. A compiler sits between the two, so a further proof checks its output.
The kernel can keep the parts of a system apart. One part cannot change another's data, read it, or take the resources it needs, unless it was granted the right to.
A system can start in the state it was designed to have, with exactly the grants its description lists.

Not every layer is finished for every processor and every configuration. That matters, and we will come back to it.

What a proof takes for granted

A proof is exactly as wide as its statement, and it stands on its assumptions. seL4 writes its own down: that the hardware behaves as its model says, that a few hundred lines of the lowest-level code are right, that the code which runs before the kernel starts has done its job. The proof of secrecy does not cover timing.

It says nothing about whether the specification asks for the right thing, and nothing about the software above the kernel. A proved kernel will faithfully isolate a program that has a bug in it. The bug is still there. It just can't reach anything else.

That is not a weakness in the proofs. It is what makes them worth having: they say precisely what they cover, so you know precisely what is left.

Where NoWayOS stands

Here is the plain position. NoWayOS runs on seL4, but no NoWayOS image is inside seL4's completed proofs today. NoWayOS uses seL4's mixed-criticality configuration, whose proofs for our processors are in progress. And seL4's proofs never did cover NoWayOS's own code. So we don't call NoWayOS “formally verified”, and we won't.

Every image says where it stands. A file beside it lists its kernel's configuration, option by option, against the one seL4 has proved. Security shows a real one.

Smaller proofs of our own

NoWayOS's code gets its assurance another way: Rust, isolation, review, testing, and proofs of a more modest kind.

Every decoder of the messages that pass between parts of a system has bounded proofs, made with a model checker called Kani. A bounded proof covers every input up to a stated size, here the longest record a decoder accepts. Inside that bound it is a real proof: no input makes the decoder panic, overflow or read out of bounds. Beyond the bound it says nothing, which is why the bound is the longest input there is.

Then we break the decoders on purpose, to make sure the proofs notice. A proof that can't fail is no better than a test that can't.

The honest size of it

A proof doesn't make anything “unhackable”. It makes one statement true, in every case, under assumptions you can read. Know the statement and the assumptions, and you know what you have.

That is why NoWayOS is built on the kernel that has them, and why it tells you, image by image, how far they reach.

Why a NoWayOS device has no shell

2026-11-13T00:00:00Z

Most attacks on a dedicated device don't go after the job it does. They go after the rest of the computer it runs on: the shell left in for maintenance, the remote-access service nobody switched off, the browser behind the application, the desktop one crash away.

That "rest of the computer" is everywhere. The gateway that carries readings out of a water works, the terminal in a power network's control room, the devices a hospital relies on, the panel on the side of a machine, the screen in a station concourse: many of them run a general-purpose operating system with one job on top, and everything else still there underneath, switched off by settings. Kiosk mode is the simplest version. Every compromise is someone finding the one setting that was missed.

Leave it out instead

NoWayOS starts from the other end. A NoWayOS image holds the device's application, the drivers that application uses, and the seL4 microkernel. That's the whole list.

There's no shell to drop into, because no shell was ever built in. No remote login to guess a password for. No desktop to escape to. No browser engine waiting for a malicious page. You can't misconfigure a setting for software that isn't there.

All of that is about the operating system. The application on top is another matter: it can sign its users in, and sign in to other systems, whenever its job calls for it. What it doesn't sit on is an operating system anyone can log in to.

We call that a Single Purpose OS: a computer with nothing else to do.

And what is there is sealed

Leaving things out is half of it. Each part that remains (the network, the screen, the input, the application) runs in a compartment of its own, a protection domain in seL4's terms, and reaches only what it was granted. The network driver moves packets. The display driver draws. The application talks to each through fixed-size messages.

Every grant is written down in a file, one fact per line, and the build fails if the system and the file disagree. It's built so that a fault in one part stays in that part.

"But how do you fix it without a shell?"

Engineers ask this first, and fairly. You don't log in to the operating system of a NoWayOS device: it has no accounts, so there's no one to log in as. You build a new image and replace the old one. Today that means building it and loading it onto the board; signed updates, checked by the device and able to fall back safely, are designed and on their way.

What you get in return is a device that starts straight into its one job, with far less to patch and far less to attack. For the systems a country runs on, that trade is the whole point.

See for yourself

The evidence for one real NoWayOS image, its grants file, its bill of materials and its seL4 configuration record, is on our security page. No sign-up, no script. Just the files.