MicroHasTEE: Bare-Metal Haskell for Type-Level Peripheral Ownership on Armv8-M
MicroHasTEE expresses TrustZone secure and non-secure firmware as one typed Haskell program, catching peripheral-ownership inconsistencies at compile time.
MicroHasTEE is a multiparty Haskell framework that models both TrustZone firmware images as participants in a single typed program, using type-level capability ledgers to track peripheral acquisition, configuration, transfer, and finalization. MicroHs compiles the shared program twice to produce separate bare-metal Secure and Non-secure firmware images. The framework rejects inconsistent resource use, post-configuration attribution changes, wrong-domain callbacks, and calls to unregistered Secure services. A door-lock case study on an STM32U5 Nucleo board produced images of 232.7 KiB and 228.4 KiB of flash with roughly 220 KiB of SRAM per domain.
- Type-level capability ledgers track peripheral ownership across TrustZone domains
- Compiles one Haskell program into separate Secure and Non-secure firmware images
- Rejects wrong-domain callbacks and unregistered Secure service calls statically
- Validated on STM32U5 with a door-lock case study
Full article200 words · extracted from arxiv.org · click to collapse
Arm TrustZone for Armv8-M isolates Secure and Non-secure software, but developers must still coordinate peripheral attribution, interrupt routing, initialization, and gateway interfaces across separately built firmware images. Inconsistent assumptions between these images can compile successfully and emerge only as faults on the target device. We present MicroHasTEE, a multiparty programming framework that expresses both firmware applications as participants in one typed Haskell program. MicroHasTEE represents peripheral authority with type-level capability ledgers and uses indexed setup computations to track resource acquisition, configuration, transfer, and finalization. Domain-specific effect types restrict peripheral operations and interrupt callbacks to the participant that holds the corresponding authority, while typed callable handles describe the Secure services available to Non-secure code. MicroHs compiles the shared program twice to produce separate bare-metal Secure and Non-secure firmware images. We implement MicroHasTEE for an STM32U5 Nucleo board, including TrustZone configuration, peripheral drivers, and a serialized gateway for cross-domain Haskell calls. For programs expressed through its interface, MicroHasTEE rejects inconsistent resource use, attribution changes after configuration, callbacks in the wrong domain, and calls to unregistered Secure services. A door-lock case study demonstrates feasibility, with firmware images occupying 232.7 KiB and 228.4 KiB of flash and approximately 220 KiB of SRAM per domain.
Text extracted automatically; images, tables and formatting may be missing. Original: https://arxiv.org/abs/2609.12580