Sentinel-32

A software safety lab using a custom 32-bit ISA, digital twins, and deterministic controls to contain untrusted firmware.

Comment

Inspiration

Now, microcontrollers like ESP32 are widely available and people make various interesting projects with it. But debugging and understanding what is actually happening may be difficult as re-flashing firmware do take some time.

A software and emulated-CPU environment could potentially solve this issue by exposing the running process with atomic-level control. So developers and learners can really understand what a system is doing.

More so, some of these microcontroller devices are used to control mission-critical systems, such as rocket launching controlling, so this lab, designed to be able to run the intended program with the ability to control everything in detail, can help with testings.

What it does

Sentinel-32 is a software-only safety laboratory for testing untrusted embedded firmware before it reaches real hardware. Its interactive demo lets users assemble and inspect S32 programs, step through every instruction, watch registers and memory change, and run simulated tank or rocket missions. Users can compare requested actuator actions with the values applied by deterministic safety rules, then review optional AI findings that never control the mission.

How we built it

It is built in Rust around S32, a custom fixed-width 32-bit, MIPS-inspired ISA (since it was too much engineering work to fully replicate a ESP32, MIPS, RISC, or similar processor).

Firmware behavior is written in assembly, while typed YAML defines the available hardware, MMIO registers, safety policies, faults, and safe states. These files compile into validated, immutable digital-twin bundles. The interpreter enforces memory permissions, capabilities, traps, and cycle budgets, while a Ratatui interface provides assembler, debugger, mission, and advisory views.

All these software runs on a Raspberry Pi 5 running QNX 8.0 Operating System.

Challenges we ran into

  • The local AI has to be tuned to make sure in-spec response can be reliably produced.
  • The CPU ISA and assembly language, specifically designed for this project, needs to be simple enough to not contain unneeded functionalities but also needs to be powerful enough to handle all the basic instruction that process data.

Accomplishments that we're proud of

  • Designed and built a very basic assembly language and CPU Instruction Set Architecture in the short amount of time.
  • Built the CPU "emulator" that can run the program accurately, with or without stepping, with the ability to playback.
  • Deployed a usable AI model on the device that can analyze verbal description and related data and give feedback.

What we learned

  • Running local AI using llama.cpp.
  • How Assembler works and how CPU works on a low-level perspective.

What's next for Sentinel-32

  • Build a more completed interface.
  • Make AI advisory more clearer and be able to indicate where the issue is occurring and suggested fixes.
  • Enable AI-powered pre-step safety and compliance check.
  • Make hardware definition more intuitive and maybe support real hardware through GPIO.
  • Make TUI support actual mission definition files and program assembly.

Built With

Share this project:

Updates

Submission history