arxiv: 2604.27570 · v1 · submitted 2026-04-30 · 💻 cs.OS

Recognition: unknown

treVM: Tiny Rust Embedded Virtual Machines with WASM on Variable Resource-Constrained Hardware

Antoine Lavandier , Bastien Buil , Chrystel Gaber , Emmanuel Baccelli

Authors on Pith no claims yet

Pith reviewed 2026-05-07 08:52 UTC · model grok-4.3

classification 💻 cs.OS

keywords WebAssemblyembedded virtual machinemicrocontrollersover-the-air updateslow-power devicescontinuous deploymentreal-time operating systemRust embedded

0 comments

The pith

treVM integrates WebAssembly to run customizable updatable code on diverse low-power microcontrollers.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper designs treVM as a scheme to host high-level WebAssembly code capsules on a general-purpose Rust embedded software platform that supports a wide range of 32-bit microcontrollers. This setup lets devices run customizable business logic in capsules while allowing secure updates over the network after deployment in the field. A sympathetic reader would care because typical embedded stacks rely on basic C/C++ APIs and limited update mechanisms, unlike the richer interactions possible on less constrained hardware. The work implements the approach in Rust and validates it through benchmarks on Arm Cortex-M, RISC-V, and Xtensa architectures to show it preserves low-power characteristics.

Core claim

treVM is a generic scheme to host high-level WebAssembly code capsules bolted on a general-purpose Rust embedded software platform, able to run on a large variety of 32-bit microcontrollers, with capsules that can be securely updated on demand over the network.

What carries the argument

treVM, the scheme that bolts WebAssembly capsules onto a Rust-based real-time operating system for execution on microcontrollers.

If this is right

Capsules can host highly customizable business logic on embedded devices.
Capsules support secure updates over the network on devices already deployed in the field.
The implementation runs across Arm Cortex-M, RISC-V, and Xtensa microcontroller architectures.
Extensive benchmarks on heterogeneous hardware confirm feasibility on commonly available boards.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

This approach could allow modular updates that reduce full firmware reflashes in large IoT deployments.
Separating business logic into capsules might simplify maintenance for networked embedded systems.
Further tests on boards with even tighter memory limits could identify practical boundaries for WASM use.

Load-bearing premise

A WebAssembly runtime can be integrated efficiently into a Rust embedded real-time operating system to run on many resource-constrained 32-bit microcontrollers without compromising low-power performance.

What would settle it

Benchmarks that measure power consumption or memory use during capsule execution on additional low-resource boards and show clear increases beyond baseline levels would disprove the efficiency claim.

Figures

Figures reproduced from arXiv: 2604.27570 by Antoine Lavandier, Bastien Buil, Chrystel Gaber, Emmanuel Baccelli.

**Figure 1.** Figure 1: Absolute execution times of each benchmark in the embench suite on view at source ↗

**Figure 4.** Figure 4: Absolute execution times of each benchmark in the embench suite on view at source ↗

**Figure 3.** Figure 3: Absolute execution times of each benchmark in the embench suite on view at source ↗

**Figure 6.** Figure 6: Peak RAM usage for the Embench suite on the Pico2W view at source ↗

**Figure 8.** Figure 8: System calls for treVM in Ariel OS. Once initially deployed, interaction with the capsules can happen through the provided CoAP server. We distinguish two levels of interaction for the capsules (i) ephemeral capsules, and (ii) persistent capsules. Ephemeral capsules are sent over the network via CoAP, launched, run to completion and then may send data back to the sender, typically as part of the same CoAP … view at source ↗

**Figure 9.** Figure 9: Cinematic of the usage and update of persistent capsules in view at source ↗

read the original abstract

Software stacks embedded on microcontroller-based hardware typically provide rudimentary APIs programmed in C/C++, basic connectivity and, sometimes, a firmware update mechanism. Such coarse mechanisms contrast with widely used APIs and more advanced networked interaction expected from software stacks deployed on less resource-constrained hardware (microprocessor-based). In this paper, we aim to bridge this gap by designing treVM, a generic scheme to host high-level WebAssembly code capsules, bolted on a general-purpose Rust embedded software platform, able to run on a large variety of 32-bit microcontrollers. Not only can treVM capsules host highly customizable business logic, but capsules can also be securely updated on demand over the network, on devices already deployed in the field. We implement treVM in Rust, on top of Ariel OS, a general-purpose RTOS, and we publish the code as open source. Based on our implementation, we validate the feasibility of treVM on commonly available boards, and we report on extensive benchmarks we performed on heterogeneous hardware including Arm Cortex-M, RISC-V, and Xtensa microcontroller architectures. As such, treVM provides a promising new framework to secure continuous deployment of embedded software on low-power networked devices.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

treVM ships a concrete Rust WASM runtime on Ariel OS with cross-architecture benchmarks and open code, but the low-power guarantee for continuous deployment stays untested because energy metrics are missing.

read the letter

The main point is that they built and shipped a working WASM layer on top of Ariel OS in Rust, letting capsules run custom logic and get updated over the network on deployed 32-bit MCUs. The code is open source and they ran it on real boards spanning Arm Cortex-M, RISC-V, and Xtensa. That integration and the validation across targets is the actual new piece; most prior embedded WASM work stayed on bigger chips or single architectures. The benchmarks give numbers on memory footprint and execution latency, which at least shows feasibility without blowing up the resource constraints. Credit for publishing the implementation so others can reproduce or extend it. The central claim about secure continuous deployment on low-power devices is where it gets thin. The stress-test note is right: if the reported numbers cover only size and speed and skip average current, sleep leakage, or energy per invocation, then small RTOS overheads could still shorten battery life in ways the paper does not address. The abstract and benchmarks treat low-power as a given once the runtime fits, but that assumption needs direct measurement to hold. No equations or fitted models here, so no circularity issues, just an engineering report. This paper is for embedded IoT developers and Rust-on-MCU teams who want to move past C firmware flashing. It has enough concrete work and open artifacts to deserve referee time; a reviewer could reasonably ask for power traces or a clearer scope on what “low-power” means in the results. I would send it out rather than desk-reject.

Referee Report

1 major / 1 minor

Summary. The manuscript presents treVM, a system for embedding WebAssembly virtual machines in a Rust-based RTOS (Ariel OS) to allow secure, over-the-air updates of application logic on resource-constrained 32-bit microcontrollers. The authors implement this on top of Ariel OS, validate feasibility on multiple boards, and provide benchmarks across Arm Cortex-M, RISC-V, and Xtensa platforms, claiming it enables secure continuous deployment without compromising low-power characteristics.

Significance. If the reported benchmarks demonstrate minimal overhead in power consumption and performance, this contribution would be significant for the field of embedded systems and IoT, as it provides a practical way to use high-level, secure, updatable code on low-power hardware where traditionally only C/C++ is used. The open-source implementation and multi-architecture support add to its value.

major comments (1)

[Benchmarks / Results section] The central claim that treVM enables secure continuous deployment on low-power devices rests on the WASM runtime not compromising low-power behavior. However, the benchmarks (referenced in the abstract and described in the results) report on feasibility, memory footprint, execution latency, and throughput across boards but do not include direct power metrics such as average current draw, sleep-mode leakage, or energy per capsule invocation. Small RTOS-level overheads could still affect battery life, leaving the low-power guarantee untested and load-bearing for the main contribution.

minor comments (1)

[Abstract] The abstract claims 'extensive benchmarks' and 'validation of the feasibility' but provides no quantitative data, tables, error bars, or specific findings, making it hard to evaluate the strength of the results from the summary alone.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive review and positive evaluation of treVM's significance for embedded systems and IoT. We address the major comment on benchmarks below and will revise the manuscript accordingly to strengthen the low-power claims.

read point-by-point responses

Referee: [Benchmarks / Results section] The central claim that treVM enables secure continuous deployment on low-power devices rests on the WASM runtime not compromising low-power behavior. However, the benchmarks (referenced in the abstract and described in the results) report on feasibility, memory footprint, execution latency, and throughput across boards but do not include direct power metrics such as average current draw, sleep-mode leakage, or energy per capsule invocation. Small RTOS-level overheads could still affect battery life, leaving the low-power guarantee untested and load-bearing for the main contribution.

Authors: We agree that direct power metrics are essential to substantiate the claim that treVM preserves low-power behavior on resource-constrained devices. While the current benchmarks establish feasibility, small memory footprint, and low execution latency across Arm Cortex-M, RISC-V, and Xtensa platforms (all of which are low-power MCUs), we did not include measurements of average current draw, sleep-mode leakage, or energy per capsule invocation. In the revised manuscript, we will add these power measurements using standard hardware setups (e.g., current probes on representative boards in active and idle states) to quantify any overhead from the WASM runtime and Ariel OS integration. This will directly test whether the system maintains the low-power characteristics required for battery-operated deployments. revision: yes

Circularity Check

0 steps flagged

No significant circularity: engineering implementation with empirical benchmarks

full rationale

The paper presents an engineering design and implementation of treVM on Ariel OS, followed by feasibility validation and benchmarks on heterogeneous hardware. No equations, derivations, fitted parameters, or mathematical claims appear in the provided text or abstract. The central contribution rests on open-source code, runtime integration, and reported performance metrics rather than any self-referential derivation or self-citation chain that reduces to its own inputs. Self-citations, if present in the full manuscript, are not load-bearing for any uniqueness theorem or ansatz. This is a standard non-circular outcome for implementation papers.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

Only the abstract is available, so the ledger reflects the high-level claims. The design rests on the feasibility of WASM execution and secure updates on constrained hardware.

axioms (1)

domain assumption A WASM runtime can be efficiently and securely executed on variable resource-constrained 32-bit microcontrollers using a Rust RTOS
This underpins the entire feasibility and benchmark claims across heterogeneous hardware.

invented entities (1)

treVM capsules no independent evidence
purpose: To host customizable high-level business logic that supports secure network updates on deployed devices
New construct introduced as the core abstraction of the treVM scheme.

pith-pipeline@v0.9.0 · 5519 in / 1367 out tokens · 69719 ms · 2026-05-07T08:52:44.503334+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

45 extracted references · 3 canonical work pages

[1]

Secure firmware over-the-air updates for iot: Survey, challenges, and discussions,

S. El Jaouhari and E. Bouvet, “Secure firmware over-the-air updates for iot: Survey, challenges, and discussions,”Internet of Things, vol. 18, p. 100508, 2022

2022
[2]

Intermittent OTA code update framework for tiny energy harvesting devices,

W. Weiet al., “Intermittent OTA code update framework for tiny energy harvesting devices,”IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 44, no. 1, pp. 77–90, 2024

2024
[3]

Low-power fast partial firmware update technique of on-chip flash memory for reliable embedded iot microcontroller,

J. Kwonet al., “Low-power fast partial firmware update technique of on-chip flash memory for reliable embedded iot microcontroller,”IEICE Transactions on Electronics, vol. 104, no. 6, pp. 226–236, 2021

2021
[4]

Operating systems for low-end devices in the Internet of Things: a survey,

O. Hahm, E. Baccelli, H. Petersen, and N. Tsiftes, “Operating systems for low-end devices in the Internet of Things: a survey,”IEEE Internet of Things Journal, vol. 3, no. 5, pp. 720–734, 2015

2015
[5]

Multiprogramming a 64kb computer safely and effi- ciently,

A. Levyet al., “Multiprogramming a 64kb computer safely and effi- ciently,” inProceedings of the 26th Symposium on Operating Systems Principles, 2017

2017
[6]

Embassy Framework,

“Embassy Framework,” https://github.com/embassy-rs/embassy, 2026

2026
[7]

Ariel OS: An Embedded Rust Operating System for Networked Sensors & Multi-Core Microcontrollers,

E. Franket al., “Ariel OS: An Embedded Rust Operating System for Networked Sensors & Multi-Core Microcontrollers,”IEEE DCOSS-IoT, 2025

2025
[8]

Rust in Android: Move Fast and Fix Things,

J. Vander Stoep, “Rust in Android: Move Fast and Fix Things,” https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix- things.html, 2025

2025
[9]

Femto-Containers: Lightweight virtualization and fault isolation for small software functions on low-power IoT microcon- trollers,

K. Zandberget al., “Femto-Containers: Lightweight virtualization and fault isolation for small software functions on low-power IoT microcon- trollers,” inACM/IFIP Middleware, 2022

2022
[10]

Scripting over-the-air: towards containers on low-end devices in the Internet of Things,

E. Baccelliet al., “Scripting over-the-air: towards containers on low-end devices in the Internet of Things,” inIEEE PerCom Workshops, 2018

2018
[11]

MicroEJ Servitization,

“MicroEJ Servitization,” https://www.microej.com, 2026

2026
[12]

Why are smart buildings still dumb: The road ahead,

K. Skrivankovaet al., “Why are smart buildings still dumb: The road ahead,” inACM SIGCOMM 2025 Posters and Demos, 2025

2025
[13]

TinyML as a Service on Multi-Tenant Microcontrollers,

B. Builet al., “TinyML as a Service on Multi-Tenant Microcontrollers,” inInternational Conference on Embedded Wireless Systems and Net- works (EWSN), 2025

2025
[14]

Cyber-physical webassembly: Secure hardware interfaces and pluggable drivers,

V . Kenhoveet al., “Cyber-physical webassembly: Secure hardware interfaces and pluggable drivers,” inIEEE NOMS, 2025

2025
[15]

Tighten Rust’s Belt: shrinking embedded Rust binaries,

H. Ayerset al., “Tighten Rust’s Belt: shrinking embedded Rust binaries,” inACM LCTES, 2022

2022
[16]

Research on webassembly runtimes: A survey,

Y . Zhang, M. Liu, H. Wang, Y . Ma, G. Huang, and X. Liu, “Research on webassembly runtimes: A survey,”ACM Transactions on Software Engineering and Methodology, vol. 34, no. 8, pp. 1–47, 2025

2025
[17]

Benchmarking webassembly for embedded systems,

K. Moron and S. Wallentowitz, “Benchmarking webassembly for embedded systems,”ACM Trans. Archit. Code Optim., vol. 22, no. 3, Sep. 2025. [Online]. Available: https://doi.org/10.1145/3736169

work page doi:10.1145/3736169 2025
[18]

How far we’ve come – a characterization study of standalone webassembly runtimes,

W. Wang, “How far we’ve come – a characterization study of standalone webassembly runtimes,” in2022 IEEE International Symposium on Workload Characterization (IISWC), 2022, pp. 228–241

2022
[19]

An empirical study of real-world webassembly binaries: Security, languages, use cases,

A. Hilbig, D. Lehmann, and M. Pradel, “An empirical study of real-world webassembly binaries: Security, languages, use cases,” in Proceedings of the Web Conference 2021, ser. WWW ’21. New York, NY , USA: Association for Computing Machinery, 2021, p. 2696–2708. [Online]. Available: https://doi.org/10.1145/3442381.3450138

work page doi:10.1145/3442381.3450138 2021
[20]

An evaluation of webassembly in non-web environments,

B. Spies and M. Mock, “An evaluation of webassembly in non-web environments,” in2021 XLVII Latin American Computing Conference (CLEI), 2021, pp. 1–10

2021
[21]

Pushing serverless to the edge with webassembly runtimes,

P. Gackstatter, P. A. Frangoudis, and S. Dustdar, “Pushing serverless to the edge with webassembly runtimes,” in2022 22nd IEEE International Symposium on Cluster, Cloud and Internet Computing (CCGrid), 2022, pp. 140–149

2022
[22]

W ASMICO: Micro-containers in microcontrollers with WebAssembly,

E. Ribeiro, A. Restivo, H. S. Ferreira, and J. P. Dias, “W ASMICO: Micro-containers in microcontrollers with WebAssembly,”Journal of Systems and Software, vol. 214, p. 112081, Aug. 2024

2024
[23]

WiProg: A WebAssembly-based Approach to Integrated IoT Programming,

B. Li, W. Dong, and Y . Gao, “WiProg: A WebAssembly-based Approach to Integrated IoT Programming,” inIEEE INFOCOM, 2021

2021
[24]

Aerogel: Lightweight Access Control Framework for WebAssembly-Based Bare-Metal IoT Devices,

R. Liu, L. Garcia, and M. Srivastava, “Aerogel: Lightweight Access Control Framework for WebAssembly-Based Bare-Metal IoT Devices,” in2021 IEEE/ACM Symposium on Edge Computing (SEC), Dec. 2021, pp. 94–105

2021
[25]

Bytecode Alliance, “W AMR,” https://github.com/bytecodealliance/ wasm-micro-runtime
[26]

Using Rust in RIOT,

RIOT Maintainers, “Using Rust in RIOT,” https://doc.riot-os.org/rust tutorials/rust in riot/, 2024, [Online]

2024
[27]

RIOT: An open source operating system for low-end embedded devices in the IoT,

E. Baccelliet al., “RIOT: An open source operating system for low-end embedded devices in the IoT,”IEEE Internet of Things Journal, 2018

2018
[28]

Wasmi-labs, “Wasmi,” https://github.com/wasmi-labs/wasmi
[29]

V . S. Steven Massey, “Wasm3,” https://github.com/wasm3/wasm3
[30]

A fast in-place interpreter for webassembly,

B. L. Titzer, “A fast in-place interpreter for webassembly,”Proc. ACM Program. Lang., vol. 6, no. OOPSLA2, Oct. 2022. [Online]. Available: https://doi.org/10.1145/3563311

work page doi:10.1145/3563311 2022
[31]

Wasm-interpreter,

DLR-FT, “Wasm-interpreter,” Online: https://github.com/DLR- FT/wasm-interpreter
[32]

Wasefire

J. Cretin, J.-M. Picod, E. Bursztein, and L. Invernizzi, “Wasefire.” [Online]. Available: https://github.com/google/wasefire
[33]

Exploring coremark a benchmark maximizing simplicity and efficacy,

S. Gal-On and M. Levy, “Exploring coremark a benchmark maximizing simplicity and efficacy,”The Embedded Microprocessor Benchmark Consortium, vol. 6, no. 23, p. 87, 2012

2012
[34]

Embench: Recruiting for the long overdue and deserved demise of dhrystone as a benchmark for embedded computing,

D. Pattersonet al., “Embench: Recruiting for the long overdue and deserved demise of dhrystone as a benchmark for embedded computing,” Computer Architecture Today Blog, Jun, vol. 11, 2019

2019
[35]

Wasm3/wasm-coremark,

“Wasm3/wasm-coremark,” Wasm3 Labs. [Online]. Available: https: //github.com/wasm3/wasm-coremark
[36]

Cretin, https://github.com/google/wasefire/issues/458#issuecomment- 3188553942, Accessed 2026-01-29

J. Cretin, https://github.com/google/wasefire/issues/458#issuecomment- 3188553942, Accessed 2026-01-29

2026
[37]

Web assembly component model,

“Web assembly component model,” https://component-model. bytecodealliance.org/, accessed: 2025-01-26

2025
[38]

https://github.com/WebAssembly/custom-page-sizes/blob/main/ proposals/custom-page-sizes/Overview.md, Accessed 2026-01-27

2026
[39]

Cyberphysical security for the masses: A survey of the Internet protocol suite for Internet of Things security,

H. Tschofenig and E. Baccelli, “Cyberphysical security for the masses: A survey of the Internet protocol suite for Internet of Things security,” IEEE Security & Privacy, vol. 17, no. 5, pp. 47–57, 2019

2019
[40]

Object Security for Constrained RESTful Environments (OSCORE),

G. Selander, J. P. Mattsson, F. Palombini, and L. Seitz, “Object Security for Constrained RESTful Environments (OSCORE),” RFC 8613, Jul
[41]

Available: https://www.rfc-editor.org/info/rfc8613

[Online]. Available: https://www.rfc-editor.org/info/rfc8613
[42]

WebAssembly Core Specification

“WebAssembly Core Specification.” [Online]. Available: https://www. w3.org/TR/wasm-core-1/
[43]

Wasmtime Security Policy

B. Alliance, “Wasmtime Security Policy.” [Online]. Available: https: //docs.wasmtime.dev/security.html
[44]

——, https://docs.rs/wasmtime/latest/wasmtime/struct.Engine.html# method.precompile module, Accessed 2026-04-29

2026
[45]

Cargo bloat,

Y . Reizner, “Cargo bloat,” https://github.com/RazrFalcon/cargo-bloat, Accessed 2026-01-27

2026