Femto-Containers: DevOps on Microcontrollers with Lightweight Virtualization & Isolation for IoT Software Modules

Abstract

Development, deployment and maintenance of networked software has been revolutionized by DevOps practices, which boost system software quality and agile evolution. However, as the Internet of Things (IoT) connects low-power, microcontroller-based devices which take part in larger distributed cyberphysical systems, such low-power IoT devices are not easy to integrate in DevOps workflows. In this paper, we contribute to mitigate this problem by designing Femto-Containers, a new hardware-independent mechanism which enable the virtualization and isolation of software modules embedded on microcontrollers, using an approach extending and adapting Berkeley Packet Filters (eBPF). We implement a Femto-Container hosting engine, which we integrate in a common low-power IoT operating system (RIOT), and is thus enhanced with the ability to start, update or terminate Femto-Containers on demand, securely over a standard IPv6/6LoWPAN network. We evaluate the performance of Femto-Containers in a variety of use cases involving one or more applications simultaneously hosted on the same microcontroller. We show that Femto-Containers can virtualize and isolate software modules executed concurrently, with very small memory footprint overhead (below 10%) and very small startup time (tens of microseconds) compared to native code execution. We carry out experiments deploying Femto-Containers on a testbed using heterogeneous IoT hardware based on the popular microcontroller architectures Arm Cortex-M, ESP32 and RISC-V. We show that compared to prior work on software-based low-power virtualization and isolation such WebAssembly for microcontrollers or small script runtime interpreters (microPython, RIOTjs), Femto-Containers offer an attractive trade-off in terms of memory footprint, energy consumption, and security. The characteristics of Femto-Containers satisfy both the requirements of software modules hosting high-level logic coded in a variety of common programming languages, and the constraints of low-level debug snippets inserted on a hot code path. CCS CONCEPTS• Computer systems organization → Embedded systems.

HArMoNICS: High-Assurance Microgrid Network Infrastructure Case Study

“…Therefore, the SUIT workflow allows an Information System Management (ISM) service to upload a firmware image containing security vulnerabilities or malicious behaviors. Furthermore, as demonstrated by some recent work, the SUIT workflow is flexible in that it allows not only pre-quantum, but also post-quantum security [22], and does not only cater for full IoT firmware updates, but also for securing modular software updates on low-power IoT devices [23]. Last but not least, SUIT allows the ISM to transfer its authority to another entity, e.g., a third-party developer, that can deliver to the ISM some components of a software update (e.g., the executable of the application to be updated) or trigger the update process directly.…”

Cubedate: Securing Software Updates in Orbit for Low-Power Payloads Hosted on CubeSats

“…We generalized the SUIT state machine to add support for (i) Heterogeneous update delivery mechanisms with configurable {message model, network stack, network interface} bundle, or FileSystem read/write functions, (ii) Heterogeneous storage destination with configurable internal/external memory either Volatile (e.g. RAM for mission files, or for tiny runtime execution containers such as Fem-toContainers [24]) or non-volatile (e.g. FileSystem or internal Flash) and (iii) Heterogeneous update data URI with either a local file (e.g.…”

[Tool] Automatically Extracting Hardware Descriptions from PDF Technical Documentation

“…Hardware vendors typically provide a HdS implementation in the C programming language only. However, newer compiled languages and dynamic runtime environments, such as C++ [34], Rust [59], Python [38], and IoT-focused Femto-Containers [80], bring new programming paradigms and features to resource-limited embedded systems, but they require a custom HdS stack [15,30].…”