Networking, TLS and the wireless half

ARP through TCP to TLS 1.3, all written for this project, plus a wireless driver that is honest about which half of itself is finished.

The stack, and the one re-entrancy rule

Three interfaces exist: loopback, wired and wireless. A driver implements one trait; start-up tries the emulated card first and the laptop's real one second. Routing picks an interface by destination, and every layer above asks for a source address rather than assuming one exists.

Polling never dispatches into a transport state machine. It queues. That rule is the one thing holding the design together, and the reason is a cycle: sending calls into IP, which calls address resolution, which polls while waiting for a reply. Running a state machine from inside that poll would let a connection re-enter its own control block while an earlier borrow of it is still live. So TCP and UDP drain their own inboxes on their own terms instead.

TCP advances only while the shell is idle or inside a blocking call. There is no interrupt-driven receive, which is a real limitation and a deliberate one at this size.

There is one TCP connection. The module holds a single control block and connecting aborts whatever was open before it, and the language's builtins expose that plainly rather than handing back a descriptor that corresponds to nothing.

One wire-level trap worth carrying away: Ethernet pads frames to 60 bytes, so a bare 40-byte acknowledgement arrives with garbage after it. IPv4 payloads have to be trimmed to the length the header declares, not to the length the frame happened to be.

Hand-written cryptography is the dangerous part

Everything here was written from scratch, and this is the one place in the project where that is a liability rather than a virtue. A bug in cryptography produces output that works perfectly and is not secure. There is no failing test to notice, because the wrong answer is indistinguishable from the right one to everything except an attacker.

So the primitives were chosen for checkability rather than for speed. ChaCha20 over AES-GCM, because it has no key-dependent table lookups and therefore no timing side channel to get wrong. X25519 over a NIST curve for the same family of reasons. Every primitive is checked against published RFC vectors at boot, and that output has caught a real break: an ECDSA failure sat visible in it for an entire debugging cycle while the log was being filtered down to the section under active work.

Signatures use Jacobian coordinates. Affine ones cost a modular inversion per point operation — a full modular exponentiation — which for P-384 came to roughly 460,000 allocating multiplications per signature and exhausted the heap. The inversion helper takes and returns ordinary values; handing it something already in Montgomery form computes the wrong thing silently, which is the same class of failure as everything else on this page.

TLS 1.3 validates the chain, the transcript signature, the dates and the name, and then reports rather than enforces. A caller that cares must check the result. There is no revocation.

Key material, and a blind spot in the entropy

Randomness comes from a fast-key-erasure construction over the same stream cipher the boot self-test already checks against published vectors. One 64-byte block per step: the first 32 bytes overwrite the key and only the last 32 leave the module, so the state that produced an output is gone before the caller sees it. That is the only way a kernel with one address space and no process isolation gets backtracking resistance.

There are two entropy sources, and the second exists because the first has a blind spot. Keyboard and mouse interrupt timing arrives through the shared pool. Disk completion latency deliberately does not — because that same pool also answers the question "is a person present", which the unattended loops consult before doing anything, so routing disk traffic through it would make an idle machine look occupied and stand down the very loop that only runs when nobody is there.

One bit is credited per event whatever the source, and 256 events are required before key material will be produced. That figure is an assumption and not a measurement, and it is the weakest link in the module. The non-secret path still answers below the threshold, for things that want unpredictability without depending on it; the secret path refuses, because a generator that quietly degrades for a private key is the failure this whole section exists to warn about.

The wireless half that is finished, and the half that is not

The laptop's wireless card is CNVi, which means the MAC lives in the chipset and the M.2 module is a radio rather than a network card. There is no driver that can make that work here, and the code says so and refuses to pretend rather than reporting a device it cannot use.

For a USB dongle, everything above the transport is written and checked at boot: probe requests are built and beacons parsed, transmit and receive descriptors are built and read back, the WPA2 handshake runs, and initialisation applies all four tables including the radio over the serial interface the radio actually needs.

What is missing is the transport in between — the link-list table, the FIFO boundary that gates the MAC's transmit and receive enables, channel selection, the fuse map, firmware upload, and handing a descriptor to a bulk endpoint. None of the chip-facing half can be exercised here, because the emulator has no model of the part, so it is stated as unproven rather than presented as working.