gust OS: runtime wasm loading on-target for the kiln on-board interpreter (distinct from build-time dissolve)

[avrabe]

Context

kiln is adding a no_std interpreter mode so it can interpret WebAssembly on-board — the alternative to synth-AOT for payloads where AOT is not wanted (dynamic/late-loaded, migrated, untrusted, or smaller-TCB cert contexts). Write-up: pulseengine/kiln#415 (decision AD-NOSTD-INTERP-001, requirement REQ_NOSTD_INTERP).

Aligns with gust's existing phase-2 kiln integration (SYSREQ-KILN-002 end-to-end verified compilation pipeline, SWREQ-KILN-003 synth ARM codegen, STKH-002 eliminate-C-FFI). kiln's REQ_NOSTD_INTERP now depends-on gust:SYSREQ-KILN-002.

The new ask (narrow)

gust's model today is build-time dissolve (verified wasm → native via meld/loom/synth, TCB ≈ 4-fn shim). The on-board interpreter needs something not yet provided:

1. Runtime wasm loading — get wasm module/component bytes to the interpreter at runtime on-target (from storage/uplink), not just link a dissolved-at-build image. This is the interpreter's whole value: running payloads that were never AOT'd.
2. Host the interpreter image — either (a) run the synth-compiled kiln image (if kiln-as-wasm→synth pans out — philosophically identical to gust's kernel-as-dissolved-wasm), or (b) link the no_std-Rust kiln staticlib (the proven baseline — exactly how kiln-async deploys today for thumbv7em).

Alignment notes

• The wasm→native-toolchain-in-TCB trust argument (your existing concern) is helped here: payloads the interpreter runs never go through synth, so they don't rely on that toolchain's trust.
• gale's north-star ("dissolved CM composition runs on the kiln/gust stack, kiln-async drives it bare metal") already proves the no_std/no_alloc embedded execution model this builds on.

Coordination

Planning/coordination issue; kiln-side tracked in kiln#415. kiln Phase-1 is a feasibility spike (kiln-as-wasm→synth go/no-go); the gust runtime-loading surface can be scoped in parallel. For the phase-2 kiln integration track.

[avrabe]

gust side — the Pixhawk 6X-RT (i.MX RT1176) makes runtime loading native, and maps cleanly onto the two cores

Grounding the runtime-loading ask in the same target as gale#164/#63 (Pixhawk 6X-RT = i.MX RT1176: M7 @1GHZ + M4 @400Mhz, 2 MB SRAM, 64 MB external XIP flash, no internal flash, SE051 secure element):

1. Runtime wasm loading is the platform's natural mode here

The RT1176 has no internal flash — it executes XIP from 64 MB external flash. So "get module/component bytes to the interpreter at runtime" isn't a bolt-on; it's how the part already works: payloads live in the external flash / a storage region (or arrive via CAN-FD / 100Base-T1 uplink) and the interpreter loads them into the 2 MB SRAM working set. gust's surface is thin: a load(bytes: &[u8]) -> instance entry plus the storage read (a gust:hal-style block/flash capability, dissolved like the mmio drivers). No re-flash, which is the whole point vs build-time dissolve.

2. Hosting the interpreter image — map to the two cores (ties in gale#63)

The RT1176's heterogeneous M7 + M4 is the deployment shape gale#63 asks for, and it splits the hybrid cleanly:

• M7 (1 GHz) = the certified dissolved hot path — flight-critical gust, meld/loom/synth AOT, TCB ≈ the 4-fn shim, no interpreter in that domain.
• M4 (400 MHz) = the interpreted / late-loaded tenants — the no_std kiln interpreter (2b, the proven thumbv7em staticlib deploy — exactly how kiln-async ships today, which gust already links no_std/no_alloc bare-metal) running runtime-loaded payloads, isolated from the M7 flight core.

So option (2b) no_std kiln staticlib is the immediate baseline (no new trust surface, ships today); (2a) synth-compiled-kiln is the Phase-1 go/no-go — and if it pans out it's philosophically identical to gust's kernel-as-dissolved-wasm, so I'm keen to see the spike land.

3. Runtime loading composes with secure-boot (gale#164)

A payload loaded at runtime should still pass the sigil reject-at-load verify (anchored in the SE051, gale#164) before the interpreter instantiates it — so load(bytes) → verify(SE051) → interpret. The interpreter's trust win you noted (payloads never go through synth) holds; the SE051 gate covers provenance instead.

Concrete gap / on-ramp

Same as gale#164: gust benches STM32 today; the Pixhawk is i.MX RT1176, so this needs an i.MX RT BSP — the external-flash/storage read capability (for runtime loading), the XIP memory map + M7 target, and the M4-side no_std kiln link. First step I can take without the board: instantiate the storage-read gust:hal capability + the load() entry against a RAM-backed model (qemu), mirroring how the mmio drivers are validated before Renode/silicon.

Tracking under the phase-2 kiln integration; happy to scope the runtime-load surface in parallel with kiln#415 Phase-1.