Furth FortuneM9 reference

Mission foundation / System overview

BenthOS

A small base for controlled devices

BenthOS provides the low-level mechanisms needed by a MerTek node: startup, memory, scheduling, device access, and host boundaries. Applications still remain Trident plus configuration.

Inside the system

Architecture plates

Each plate preserves the internal layout, paths, boundaries, and highlighted decisions. Use the short label first, then follow the lines through the system.

Plate 01

BenthOS owns the mechanism and none of the policy

policy above · mechanism in the middle · two hardware tracks below

MERTEK OWNS THE POLICY BENTHOS REFUSES TO BE Trident applicationsconfig plus .tri, never app-specific C Fathomroutes, sessions, reconnect, protocol state Thalassa and Glintscenes, one render IR, five backends MerDBtyped entities, indexes, blobs, streams MerFSthe durable storage substrate below MerDB BenthOS native/benthos/ · 7 C-family source files OWNS THE MECHANISM, AND ONLY THE MECHANISM memory protection and paging capabilities and grants interrupts and timers queues, rings, one doorbell block storage lanes network frame lanes a boot manifest and an init bundle a framebuffer fallback x86_64 · UEFI · PCI virtio-blk-pci, virtio-net-pci, IDT, PIC, PIT aarch64 · UEFI · virt virtio-mmio block and net, GICv2, cntv BenthOS is not a Linux distribution a POSIX compatibility target a package manager a POSIX-first userland a broad legacy device surface an arbitrary app model socket-native; it is network-native filesystem-first; it is page-first a home for scenario policy THE SEAM TODAY 0 files outside native/benthos include benthos_api.h or name a benth_ symbol. The substrate is proven in isolation, and the benthos-substrate section declares no trident exercise layer.
Plate 02

Boot is an ordered cascade, and every stage fails closed

UEFI loader · kernel stage order · the three refusals

1 · UEFI LOADER · THE x86_64 ESP CARRIES FOUR FILES load KERNEL.ELFvalidate ELF64, place PT_LOAD load MAN and MERfrom the FAT32 ESP root manifest vs bundlemagic, size, kind, checksum build BenthBootInfo, exit_boot_services, then jump to the kernel the loader refuses It returns an EFI status and never jumps, so the firmware keeps the machine. 2 · KERNEL · benth_kernel_main · THE x86_64 STAGE ORDER 01 serial_init · kernel.entry 02 benth_boot_info_valid 03 normalize_memory_map 04 choose_early_allocator 05 install_identity_paging 06 install_interrupt_substrate 07 install_timer_substrate · prove_timer_tick 08 init_boot_queue_set 09 probe_storage_device · probe_network_device 10 declare_root_arena 11 publish_boot_assets 12 publish_supervisor_domain … control 13 execute_supervisor_entry 14 storage seed · drain · RX refill · drain 15 submit_network_packet_probe 16 framebuffer · kernel.survival · hlt kernel_panic() Each stage returns 0 or 1. A 0 calls kernel_panic, which writes the reason to serial and halts. 23 panic sites on x86_64. 21 on aarch64. No stage falls through. 3 · THE GATE · WHAT THE PROFILE RECORDS WHEN THE MACHINE CANNOT BOOT run-preflight.sh--require-ready READYthe QEMU boot smoke runs BLOCKEDexit 77 · unavailable A SKIP WOULD BE THE WRONG INSTRUMENT chk_skip cannot carry this. The prelude refuses a leaf whose results are all skips as vacuous, and an absent QEMU is an absent capability, not a defect in the code.
Plate 03

One record shape, one predicate, one event line

the 64-byte layout · produce, validate, publish, read back

ONE SHAPE · 64 BYTES · 30 STRUCTS ASSERTED AT COMPILE TIME magic0 abi8 uint6416 uint6424 uint6432 uint6440 uint6448 uint6456 uint16 flags · bytes 14 to 16 uint16 state or kind · bytes 12 to 14 THE SAME SHAPE, ONE WORKED EXAMPLE BenthSupervisorControlDesc: magic · abi_version · state · flags · domain_id · lifecycle_generation · storage_command_ring_id · network_command_ring_id · completion_ring_id · doorbell_id PRODUCE · VALIDATE · PUBLISH · READ BACK the kernel fillsa zeroed struct benth_*_valid72 predicates, all total post_boot_queue_descone BenthDesc in ring 1 a serial linebenthos-event: the gategreps for it false → return 0→ kernel_panic, halt
Plate 04

A command must prove its grant before the kernel touches the device

the command ring · the ordered proofs · one refusal path

THE SUPERVISOR PRODUCES · THE KERNEL CONSUMES INIT.MER 6 seed commands, written by build-x86_64.sh command ring 2 capacity 64, owner domain 1 the supervisor produces the kernel drains it one cursor, in order producer 6 · consumer 6 completion ring 1 one BenthStorageIoResult under each consumed token the grant table · 5 capabilities root arena · queue set · doorbell · manifest · init bundle Doorbell 1 carries the completion ring producer index after a post. WHAT A COMMAND MUST PROVE, IN ORDER 01 the control surface is ready supervisor_control_ready, and all three rings exist 02 the ring is sane the consumer is not ahead, and the backlog fits the capacity 03 completion capacity is reserved pending plus one must fit, BEFORE the device is touched 04 the descriptor validates benth_storage_command_desc_valid, and aux0 names device 1 05 the payload is grant-covered benth_capability_covers_memory_object_range, or the kernel owns it 06 the drain descriptor validates and the read, write, and readback checksums all match any no → return 0 drain_storage_command_ring returns 0. publish_storage_command_drain returns 0. benth_kernel_main calls kernel_panic with "storage command drain declaration failed". There is no fallback to an un-granted read, and no way to skip the command. The machine stops. RIGHTS THE CAPABILITY MUST HOLD a READ command → READ, WRITE and MAP a WRITE command → READ and MAP The kernel writes into the buffer on a READ, so a READ needs WRITE on the memory object it targets.

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.

Mechanism, not mission policy

The substrate manages basic device actions and records. It does not decide what the mission should do.

Specific example

A radio interface can expose send and receive functions while the application controls when communication is allowed.

Ordered startup

Each startup stage checks its inputs before the next stage runs. Failure stops safely and leaves a useful record.

Specific example

An edge node can refuse to enter service if its identity or required configuration cannot be verified.

Capability checks

A command must show that it is allowed before the substrate touches a device. The check happens at the boundary closest to the hardware.

Specific example

A maintenance tool can read a sensor only when its current grant permits that exact action.

Uses

Example uses

Pilot questions

What the team must decide

Which hardware needs a narrow trusted base

What the node must verify before service

Which device actions require explicit grants

Request a technical briefing

Connected references

Mission foundation Fathom Open reference Assurance fabric Security and Tenancy Open reference Assurance fabric Controlled Deployment Open reference
Return to the M9 reference library