Drivers for hardware we have never seen

Picture a small engineering firm that builds its own field terminal. A single-board computer from one maker, a display from another, a cellular modem bought because it was in stock, and a sensor board a colleague designed over a few evenings. Nothing about this machine exists anywhere else.

The person who assembled it writes the install key, plugs it in and waits. The system comes up, the display works, the modem does not. No error on screen, just a network that never appears. Two days later the cause turns out to be a driver pulled from a forum thread, compiled against a kernel nobody will ever update again. The hardware is fine. The way the system treats what it does not know is the problem.

The real cause

A general-purpose distribution promises to run on everything, and keeps that promise by shipping everything: tens of thousands of drivers, some of them binary blobs nobody outside the vendor can inspect. An opinionated system cannot make that promise. It has to say which hardware it stands behind, which it merely tolerates, and what happens when it meets a board it has never seen. Most systems never say, and the gap gets filled by guesswork.

Where unknown hardware goes wrong

The compatibility list is implied. “Runs on ARM and x86” sounds like a list and is not one. Without a declared set of tested boards, every install is an experiment, and the system cannot tell a supported configuration from a lucky one.

Drivers arrive as blobs. A binary driver from a vendor is a piece of kernel-level code nobody can review, pinned to one kernel version, with a licence that may forbid redistribution. On a system that claims to be readable from the kernel up, one blob makes the claim false.

One missing driver stops the boot. A system that treats every piece of hardware as essential fails entirely when one piece is absent. A missing modem should mean no network, not a machine that never reaches a login prompt.

Workarounds live outside the system. A kernel module built by hand, a script in a home directory, an out-of-tree patch. They work until the next update and leave no record that would let anyone reproduce the setup.

Failure is silent. No status line says “this sensor is unknown”, so the owner learns about it from the absence of data, weeks later.

The vendor becomes the maintainer. Once a board depends on code only its maker can update, the maker’s schedule becomes the security schedule.

How KyberLinux intends to handle hardware it does not know

The plan for KyberLinux is not to run on everything. It is to be honest about what it runs on, and to make the unknown a visible, reviewable and recoverable state.

A small supported core. A short list of reference targets, each one actually booted, with the whole chain from firmware to runtime checked. Short on purpose: a claim we can keep is worth more than a long list we cannot.

A declared compatibility list, with its status. Every board we have an opinion about gets one of a few plain states: supported, builds but untested, known not to work. The list is a public file, so a board’s status is a fact anyone can read, not a rumour on a forum.

Drivers as reviewed packages. A driver enters the image the way any other component does: as source, in a change anyone can read, built reproducibly, signed with the rest. It is the same rule that makes reproducible builds a supply chain argument. A driver that cannot meet that bar does not go into the base image.

Degrade, do not die. Nothing beyond the core the board needs is marked essential. A sensor that is missing, unknown or refusing to initialise shows up as a missing sensor in the system’s own status, where the owner and the SI can both see it. The machine still comes up, still updates and still rolls back.

A fork is a first-class path. A board we have never seen is a change to a public image definition, not a request to us. If you build your own deck, your target can live in your fork with the same build, verification and update mechanism as ours.

What the maintainers refuse to ship

Binary blobs in the base image. If the only way a board works is a driver nobody can read, the base image does not carry it. A fork may accept the blob; the choice is then the owner’s, in writing, not ours by default.

Out-of-tree patches without a path upstream. A patch carried forever against every new kernel is a debt the whole system pays. We take one when there is a plan to stop needing it.

A compatibility claim without a boot. Nothing goes on the supported list because the datasheet looks right. A board is supported when someone has booted it, updated it, rolled it back and verified the image on it.

Hardware that disables verification. A target that only works with verified boot switched off can run the system, but it cannot be listed as supported, and its status says so.

The limit is plain: today no board is supported, because the system is not released. These are rules we intend to apply, not hardware they have been applied to, and no hardware maker is a partner.

A test you can run today

Take the board you would build your deck around and list every chip that needs a driver: the SoC, wireless, the modem, the display controller, every sensor. For each, answer two questions in writing. Is the driver in the mainline kernel, as source? If not, who publishes it, and when did they last update it?

Then sort the list into three piles: mainline, vendor source, vendor binary. The first is the part of your deck any readable system can stand behind. The second is work someone can review. The third will always belong to its maker, whatever operating system you put on it. If the third pile holds the modem or the SoC, the deck is not yours yet, and no install key will change that.

What a system can do is tell you the truth about each pile, keep working when one is empty, and write down what it saw. That last part is the subject of the next post: logs an agent can read and a person can understand. And if the board in question is one you already own, start with KyberLinux on hardware you already own.