Furth FortuneEngineering reference
TECHNICAL DOCUMENTATION

2028 · MerTek systems

On this page

Core system / System overview

BenthOS

The device operating system, written in Cutlass

BenthOS is the operating system MTK runs on devices it controls end to end, such as pump-station gateways, kiosks and survey drones. It boots directly on the hardware, verifies each startup stage before the next one runs, and checks a capability before any device action. Applications stay Trident plus configuration: device changes reach them as typed events, and files reach them as scoped MerFS capabilities.

Worked example

Pump-station gateways that refuse an altered image

A water utility runs 300 sensor gateways in its pump stations. Each one reads a chlorine probe every 10 seconds and must keep its readings through radio outages of a week or more. An altered gateway image must not start, and a maintenance laptop plugged into a station must not be able to change the probe's calibration.

  1. Firmware authenticates the BenthOS loader, and the loader checks everything after it. The loader is a Cutlass program built for the UEFI loader target at firmware privilege. It verifies the signed boot manifest with the root key compiled into it and refuses any generation below the TPM rollback floor.

    # The BenthOS loader: a COFF image the firmware runs under the UEFI convention.
    text arch = "x64"
    text[] features = ["invtsc"]
    u32 word = 64
    text endian = "little"
    text memoryModel = "x86tso"
    text entryAbi = "uefi"
    text objectFormat = "coff"
    text os = "none"
    text privilege = "firmware"
    bool redZone = false
    u32 stackAlign = 16
    text entry = "efiMain"
    text coreId = "x64.apicId"
    text clock = "x64.tsc"
    u32 separationBytes = 128
    text profile = "release"
    text optimize = "size"
  2. The kernel climbs a fixed ladder: memory and protection, then queues and interrupts, then drivers, storage providers, the first supervisor, and finally the MerFS root. Each step rests only on the steps below it. Memory and cores come from the loader's handoff, never from probing.

    memory ram from handoff.map with { reserve = [kernelImage, bootStack] }
    
    cores from handoff.topology with { max = 64 }
    
    traps idt with { target = x64.idt, section = ".text.vectors" } {
        divideError = onDivide,
        pageFault = onPageFault,
        timer = onTimer,
    }
    
    interrupt void onTimer(ref<Frame> f) {
        raw { cutarch.x64.out8(0x20, 0x20) }
    }
  3. The probe port is a declared device. Its register block, address, interrupt and handler are fixed when the kernel is compiled, so no driver finds hardware by guessing. The handler records the byte and returns; what a reading means is decided above the kernel.

    struct ProbePort with { endian = little, layout = declared } {
        u32 data,
        u32 status,
    }
    
    static atomic<u8> lastByte = 0
    
    device ProbePort probe0 with { space = mmio, address = 0x09000000, irq = 33, handler = onProbe }
    
    interrupt void onProbe(ref<Frame> f) {
        u8 b = u8(probe0.data & 0xFF)
        cut.atomic.store(lastByte, b, order = release)
    }
  4. Programs reach the kernel through one declared syscall table. Every row that touches a device, a shared segment or a file scope takes a slot from the caller's own capability table. The kernel checks the holder, rights, delegation chain and expiry before it looks the resource up.

    syscall authority with { target = x64.systemCall } {
        grantReceipt = onGrantReceipt,
        launch = onLaunch,
        principal = onPrincipal,
        capability = onCapability,
        capNarrow = onCapNarrow,
        capDelegate = onCapDelegate,
        capMove = onCapMove,
        capReceive = onCapReceive,
        capDrop = onCapDrop,
        capRevoke = onCapRevoke,
    }
  5. The Trident application on the gateway handles each reading as an event and writes it through its readings anchor. On BenthOS the host backs that anchor with a MerFS scope the authority service granted. The same source runs unchanged on a hosted server.

    chest main() {
        chest state = {}
        return state
    }
    
    on event("probeReading", const chest reading) {
        u32 station = reading.station
        u64 sequence = reading.sequence
        f64 chlorine = reading.chlorine
        text name = "station-" + text(station) + "/" + text(sequence) + ".txt"
        u64 written = t.io.writeText("readings", name, text(chlorine))
        if (chlorine < 0.2) {
            t.log.warn("low chlorine at station " + text(station))
        }
    }
What happened

In acceptance testing, an image with one changed byte in its init bundle stopped at the loader with a named refusal. A maintenance laptop holding a read-only probe capability asked to write the calibration register and got fault.denied; the register never changed. Through a 6-day radio outage, gateway 117 kept 51,840 readings in its MerFS scope and sent them when the link returned.

System diagram

Small trusted base

Each layer has one job. Application choices do not enter the kernel or device mechanisms.

  1. Application Trident + configuration
  2. Platform runtime data • render • host API
  3. BenthOS mechanisms memory • schedule • devices
  4. Hardware CPU • display • radio • storage

Inside the system

How the parts work together

Follow the data, decisions, and access boundaries. Each diagram explains a concept used by applications.

Map 01

The device boundary

Hardware starts BenthOS, BenthOS supplies device mechanisms and MerFS scopes, and the host lends applications only what their grants name.

  1. Hardware startup boundary
  2. BenthOS device mechanisms
  3. MerFS scoped file system
  4. Application host declared capabilities
Map 02

Two host environments

Hosted MTK reaches its operating system through host adapters. On a device, BenthOS supplies startup, devices and files under the same application source.

  1. Existing host OS native platform adapters
  2. Hosted MTK admitted services
  3. BenthOS device startup + files
  4. Application source Trident + configuration

Key parts

What the system does

These are the main boundaries, inputs, outputs, and failure rules. The examples show a specific use of each part.

Fail-closed boot

Each startup step verifies what the next one needs before it runs. The checks cover the signed manifest, memory map, device identities, storage barrier, supervisor grants and MerFS root. A failure stops with a named refusal, never a smaller system that skipped a check.

For example

A gateway whose manifest generation sits below its TPM rollback floor refuses as rollback and never starts the kernel.

Capability before device action

A program reaches a device, a shared segment or a file scope only through a slot in its own capability table. The kernel checks holder, rights, delegation chain and expiry before it looks the resource up, so a refusal reveals nothing about what exists.

For example

A maintenance tool holding a read-only probe capability gets fault.denied when it asks to write the calibration register.

Mechanism in the kernel, policy above it

The kernel owns protection, page tables, scheduling, interrupts, queues and device lanes. MerFS owns files, and Trident owns what a reading means. Network drivers hand up frames; connections and routes live above the kernel.

For example

The radio driver exposes frame queues. Whether a gateway uploads now or waits for its window is a Trident decision.

Code

BenthOS in code

Each example is short and complete enough to read on its own. Hover a dotted word for its definition.

Chest

The kernel is built for its own target

privilege = kernel admits privileged intrinsics, and memory = handoff means the kernel's root memory comes from the loader's handoff record. redZone = false is the usual kernel rule: an interrupt pushes its frame just below the stack pointer, so no function may keep data there.

# The BenthOS kernel: a placed ELF image at kernel privilege.
text arch = "x64"
text[] features = ["invtsc"]
u32 word = 64
text endian = "little"
text memoryModel = "x86tso"
text entryAbi = "cutlass"
text objectFormat = "elf"
text os = "none"
text privilege = "kernel"
bool redZone = false
u32 stackAlign = 16
text entry = "kernelMain"
text coreId = "x64.apicId"
text memory = "handoff"
text clock = "x64.tsc"
u32 separationBytes = 128
text profile = "release"
text optimize = "speed"
Cutlass

A device program declares its grant

The grant is a requested maximum. The installer signs it into the kernel's policy, and a launcher whose own authority does not cover it gets fault.denied. Each entry arrives at start as a capability in the program's table; nothing is found by probing.

program probed with {
    memory = 16MiB,
    grants = [files(calibration, read), segments([batches]), devices([probe0]), channels([uplink])],
    launch = [gatewayHost],
}
Cutlass

Capabilities move; they are never copied

A capability lives in a declared table slot. move empties the sender's slot before the receiver's slot goes live, so no moment exists where both hold it. A capability rebuilt from bytes has no spelling.

static cap<Directory, rights=read>[4] dirs
static cap<Segment, rights=map|read>[16] views

void shareBatches() {
    views[0] = batches.capability(read) else fail
    uplink.send(views.move(0)) else fail
    views.drop(1)
}
Cutlass

A buffer changes owner with the message

The segment is declared once, with its layout, buffers and roles. Giving a batch away unmaps it from the giver before the kernel publishes the handoff.

struct Batch with { layout = declared } {
    u32 station, u32 count,
    u32[256] values,
}

segment Batch batches with { buffers = 3, producer = probed.sample, consumer = uplink.forward }
channel<Handoff, 4> batchReady with { segment = batches }

# In the probe service.
Batch b = batches.take() else fail
fill(b)
batchReady.send(batches.give(b)) else fail

# In the uplink.
Handoff h = batchReady.receive() else fail
Batch mine = batches.accept(h) else fail

Uses

Example uses

  • Pump-station and substation gateways
  • Kiosks that run one application
  • Survey drones and field sensors

Review questions

What the team must decide

Which hardware and boot firmware the device image must cover

Which devices and file scopes each program needs

How long a device must hold data while offline

Contact us
FURTH FORTUNE / ENGINEERING REFERENCEBack to top ↑