Femto-Containers Lightweight Virtualization and Fault Isolation For Small Software Functions on Low-Power IoT Microcontrollers_2

2025-04-27 0 0 881.93KB 12 页 10玖币

侵权投诉

Femto-Containers: Lightweight Virtualization

and Fault Isolation For Small Soware Functions

on Low-Power IoT Microcontrollers

Koen Zandberg

Inria

France

Emmanuel Baccelli

Inria

France

Freie Universität Berlin

Germany

Shenghao Yuan

Inria

France

Frédéric Besson

Inria

France

Jean-Pierre Talpin

Inria

France

ABSTRACT

Low-power operating system runtimes used on IoT microcontrol-

lers typically provide rudimentary APIs, basic connectivity and,

sometimes, a (secure) rmware update mechanism. In contrast,

on less constrained hardware, networked software has entered

the age of serverless, microservices and agility. With a view to

bridge this gap, in the paper we design Femto-Containers, a new

middleware runtime which can be embedded on heterogeneous

low-power IoT devices. Femto-Containers enable the secure deploy-

ment, execution and isolation of small virtual software functions

on low-power IoT devices, over the network. We implement Femto-

Containers, and provide integration in RIOT, a popular open source

IoT operating system. We then evaluate the performance of our

implementation, which was formally veried for fault-isolation,

guaranteeing that RIOT is shielded from logic loaded and executed

in a Femto-Container. Our experiments on various popular micro-

controller architectures (Arm Cortex-M, ESP32 and RISC-V) show

that Femto-Containers oer an attractive trade-o in terms of mem-

ory footprint overhead, energy consumption, and security.

1 INTRODUCTION

An estimated 250 billion microcontrollers are in use today [1]. An

increasing percentage of these microcontrollers are networked and

take part in distributed cyber-physical systems and the Internet of

Things (IoT) we increasingly depend upon. For example, such low-

power microcontrollers are at the core of hundreds of millions of

connected machines such as sensors and actuators relied upon not

only in smart homes, but also in other networked areas of the IoT

and industrial contexts (Industry 4.0). On such hardware, the total

memory available (for the whole system) is in the order of tens or

hundreds of kBytes, without virtual memory management (MMU),

often also without hardware memory protection (MPU). Neither

Linux (or derivatives/equivalents) nor traditional hypervisor can

be used as software platform on such hardware, and in eect the

challenge of deploying and maintaining distributed low-power IoT

software is exacerbated.

If you cite this paper, please use the ACM MIDDLEWARE’22 reference: K. Zandberg,

E. Baccelli, S. Yuan, F. Besson, JP Talpin. Femto-Containers: Lightweight Virtualization

and Fault Isolation For Small Software Functions on Low-Power IoT Microcontrollers.

In Proc. of 23rd ACM/IFIP MIDDLEWARE, Nov. 2022.

Recently, with the wider availability of low-power operating

systems alternatives [

] and adequate network stacks, low-power

IoT software has made giant leaps forward; but fundamental gaps

remain compared to current practices for networked software. In

fact, current state-of-the-art for managing, programming, and main-

taining eets of low-power IoT devices resembles more PC system

software workow from the 1990s than today’s common software

practices. Simplistic application programming interfaces (APIs) of-

fer basic performance and connectivity, but no additional comfort.

However, since the 1990s, networked software was revolution-

ized many times over. Networked software has entered the age of

server-less, micro-services and agility. In the eld, software modules

that are deployed and running are expected to be quickly updat-

able in terms of functionalities, and in terms of bug xes. Addi-

tional layers and primitives providing cybersecurity, exibility and

scalability became crucial: virtual machines, script programming

(e.g. Python, Javascript), lightweight software containerization (e.g.

Docker, Function-as-a-Service [

] etc.). DevOps [

] workow dras-

tically shortened software development/deployment life cycles to

provide continuous delivery of higher software quality.

In such a context, low-power IoT devices based on microcontrol-

lers are the new ‘weakest link’ within distributed cyber-physical

systems. Indeed, state-of-the-art primitives for ’serverless’, includ-

ing lightweight virtual machine (VM) runtimes [

] and container

runtimes (e.g. Docker) are not applicable on low-power devices:

they typically depend on operating systems and larger resources

which don’t t microcontrollers. In particular, VMs are either too

prohibitive in terms of hosting engine memory resource require-

ments (e.g. standard Java virtual machines), or restricted to very

specic use cases (e.g. JavaCard). This lackluster creates bottle-

necks that severely impact both exibility and cybersecurity in the

low-power IoT space.

Goals of this paper –

We aim to design a middleware func-

tion runtime adequate for heterogeneous microcontrollers. Mainly

enabling the secure deployment, execution and isolation of small

virtual software functions on low-power IoT devices. What we aim

for in priority is small start-up time for deployed functions, and

negligible overhead w.r.t. memory footprint on the microcontroller

when adding a hosted function runtime to the OS, compared to the

same functionality implemented natively (in the OS).

arXiv:2210.03432v1 [cs.OS] 7 Oct 2022

., . .

Contributions –

In this paper, the work we present mainly

consists in the following:

•

We propose Femto-Containers, a novel middleware for the

abstraction, secure deployment, execution and isolation of

(multiple, concurrent) software functions on heterogeneous

microcontroller-based IoT devices. We design Femto-Containers

as an extension of rBPF virtual machines;

•

We benchmark ultra-lightweight virtualization techniques

based on Python, WebAssembly, JavaScript and eBPF. We

show that, comparatively, a Femto-Container runtime based

on eBPF virtualization requires 10x less memory footprint;

•

We provide an open source implementation of Femto-Containers,

which we integrate in practice on a common, general-purpose

operating system for low-power networked microcontrollers

(RIOT);

•

We formally verify key components of our Femto-Container

implementation, guaranteeing fault-isolation amongst con-

current Femto-Containers, and the underlying OS;

•

We evaluate the performance of Femto-Containers in a vari-

ety of use cases, on the most popular 32-bit microcontroller

architectures: Arm Cortex-M, ESP32 and RISC-V.

2 MULTI-TENANT SOFTWARE SCENARIOS

ON MICROCONTROLLERS

Software on low-power IoT devices is growing complexity, driven

by cybersecurity, interoperability, and device management require-

ments. In practice, the development of embedded software com-

ponents is therefore often delegated to distinct entities. For secu-

rity and privacy reasons these distinct entities have limited mutual

trust [

]. For example, in this context, prior work such as Amulet [

]

aim to isolate multiple applications from each other on a micro-

controller, and to protect the underlying OS from application code.

Furthermore, maintenance of these low-power IoT devices typi-

cally requires on-the-y instrumentation. Safety requires that hot

insertion of instrumentation code cannot break running software

(already deployed). For example, prior work such as TockOS [

]

aims to enable safe multiprogramming of low-power microcontrol-

lers.

In this context, we identify the following categories of use-cases,

depicted in Figure 1:

(1)

Use-case 1: Hosting and isolation of a high-level business

function. This function can be updated securely, on-demand,

remotely over the low-power network. The execution of this

type of logic is typically periodic in nature, and has loose

(non-real-time) timing requirements.

(2)

Use-case 2: Hosting and isolation of debug and monitoring

code functions at low-level. These are inserted and removed

on-demand over the network. The functions must not inter-

fere with existing code on the device. Comparatively, this

type of function is short-lived and exhibits stricter timing

requirements.

(3)

Use-case 3: Hosting and isolation of several functions, man-

aged by several dierent tenants.

Users in the above scenarios are provided with an event-driven

programming model and ne-grained computational space, hosted

Figure 1: Container runtime use on IoT microcontrollers.

on-demand on eets of designated low-power IoT devices. Further-

more, the API available for a function fundamentally abstracts away

most of the hardware and the OS. Conceptually, these scenarios

thus partly mimic a Function-as-a-Service (FaaS) programming

model [3].

As with FaaS, multiple functions provided by distinct stakehold-

ers must run on a single device. For example OEM rmware may

have to be completed/customised by separate components, e.g. dif-

ferent developers/tenants may provide drivers separately, which

should be fault-isolated and restricted to using only driver-relevant

resources. Meanwhile, OS maintainers can deploy/run debug snip-

pets inserted elsewhere in the embedded code.

However, as a stable high-throughput network connection can-

not be assumed, storage capability is restricted to device-local stor-

age. Furthermore, scalability aspects of FaaS and container tech-

niques (e.g. running thousands of containers on a single machine)

do not play a signicant role here. Instead, the scenarios we identify

above require running just a handful of isolated functions on top of

the embedded OS. However, considering potentially large eets of

IoT devices, the scenario may nevertheless involve a large number

of containers (but across a large number of devices).

In this paper, we focus primarily on the middleware embed-

ded in the devices: the runtime permitting to host, run and isolate

functions, on-demand, on heterogeneous low-power IoT devices

deployed in the eld, based on popular 32-bit microcontroller ar-

chitectures (such as the ARM Cortex-M class, RISC-V or ESP32).

3 THREAT MODEL

When a client deploys functions on a device operational in the

eld, the embedded environment has to ensure these functions are

sandboxed. In our threat model, we consider both malicious tenants

which can deploy malicious code and malicious clients which can

maliciously interact with deployed code [9].

Malicious Tenant

: The malicious tenant seeks to gain elevated

permissions on the device it has already a set of permissions on. This

tenant is already allowed to run code in the sandboxed environment,

and the tenant might want to break free from the sandbox to either

the host system or a dierent sandbox it doesn’t have permissions

for. While a tenant has to work within the permissions granted by

the host service, it can make free use of the granted resources.

Malicious Client

: The malicious client doesn’t have any per-

missions for running sandboxed code on the device. The only access

the malicious client has is access to networked endpoints exposed

Femto-Containers ., .

by the device, e.g. CoAP endpoints exposed by existing sandboxed

environments. The malicious client seeks to gain any permission

on the device to inuence it or gain access to condential data

on the device. The malicious client could make use of an already

vulnerable tenant function.

A number of attack vectors are considered in this work:

•

Install and update time attacks: These attacks focus on modi-

fying the application during the transport to the sandbox en-

vironment. This includes man-in-the-middle modications

to the applications.

•

Privilege escalation to a dierent sandbox: This class of at-

tacks focus on escaping the sandbox of the application to

a dierent sandbox. The new sandbox could have dierent

permissions.

•

Privilege escalation to the operating system: This attack class

attempts to escape the sandboxed environment altogether

to the operating system.

•

Resource exhaustion attacks: The devices considered here

have very limited resources, both computational power and

battery energy are limited. A denial of service vector can be

to exhaust these resources.

Within the Femto-Container design we consider network attacks

to exhaust resources on the system to be out of scope, this type

of attack should be guarded against by the embedded operating

system.

4 RELATED WORK

Typically, the fundamental building block for middleware embedded

on devices allowing for generic function deployment and execution

is a virtual machine runtime.

The vast majority of prior work on lightweight virtualization

runtimes [

] does not target microcontrollers, but microprocessor-

class computers. Recent examples include for instance AWS Fire-

cracker [

] for serverless computing, WebAssembly [

] for pro-

cess isolation in Web browsers, or eBPF [

] for debug and

inspection code inserted in the Linux kernel at run-time.

However, some ultra-lightweight virtualization approaches have

been proposed for microcontrollers. For example, minimized Web-

Assembly runtimes adapted to run on 32-bit microcontrollers were

proposed, such as WAMR [

] and WASM3 [

]. RapidPatch [

]

uses an eBPF runtime to provide a hotpatching framework for RTOS

rmwares.

VM runtimes for microcontrollers include also earlier exam-

ples such as Mate [17] or Darjeeling [18], a subset of the Java VM,

modied to use a 16 bit architecture, designed for 8- and 16-bit mi-

crocontrollers. JavaCard [

] also uses a small Java virtual machine

tailored for cryptographic purposes, running on smart cards.

Recently, tiny scripted logic interpreters and runtimes have also

been proposed to provide a basic virtualization environment. For

instance, MicroPython [

] is a very popular scripted logic inter-

preter used on microcontrollers. Small Python runtimes are used on

ESP8266 microcontrollers in prior work such as NanoLambda [

Small Javascript runtimes are used on Cortex-M microcontrollers

in prior work such as RIOTjs [

]. However, complementary mech-

anisms should however be used to guarantee mutual isolation be-

tween scripts (such as SecureJS [23]).

The most closely related work was published in [

] and in [

In [

], authors provide rBPF, a port of the eBPF instruction set in

order to host a (single) VM on a microcontroller. In contrast, we

extend rBPF’s instruction set architecture and VM core with an ade-

quate embedded loading and execution environment, which caters

for well-dened, event-driven, short lived and isolated (concurrent)

execution of (multiple) functions to be deployed on-the-y on a

networked microcontroller. On the other hand, while [

], concerns

formal verication of the sole rBPF instruction interpreter, here

we also verify the pre-ight instruction checker and we integrate

both in our femto-container implementation – the performance of

which we thoroughly evaluate on various microcontrollers. Our

design and implementation are so small (a few hundreds lines of

code) that formal verication was indeed realistic. Comparatively,

software alternatives (WASM, MicroPython...) would require hun-

dreds of thousands of lines of code, and magnitudes more lines of

proof, all but voiding concrete perspectives of formal verication.

Hardware alternatives (e.g. TrustZone [

]) are, to the best of our

knowledge, not formally veried, and may require a software API

to avoid unspecied hardware behaviours, hence faults.

To the best of our knowledge, our work provides the rst for-

mally veried middleware based on eBPF virtualization able to host

multiple tiny runtime containers on a wide variety of heterogeneous

low-power microcontrollers.

5 EMBEDDED RUNTIME ARCHITECTURE

DESIGN

In this section, we introduce Femto-Containers, a new embedded

runtime architecture tailored for constrained IoT devices, as de-

scribed in the following.

Similarly to a FaaS runtime, Femto-Containers allow for the we

deployment and execution of small logic modules. These modules,

or functions, are hosted on top of a middleware oering isolation,

abstraction and tight isolation with respect to the underlying OS

and hardware. By combining isolation and hardware/OS abstraction,

we retain the crucial properties of FaaS runtimes: code mobility and

cyber-security. Dierently from typical FaaS runtimes, however,

Femto-Containers must be able to interact with specic hardware

(e.g. sensor/actuators), and must drastically reduce the scope and

the cost of virtualization to make do with IoT hardware constraints.

The Femto-Container architecture therefore relies on ultra-light-

weight virtualization, as well as on a set of assumptions and features

regarding an underlying RTOS, dened below.

Use of an RTOS with Multi-Threading.

It is assumed that the

RTOS supports real-time multi-threading with a scheduler. Each

Femto-Container runs in a separate thread. Well-known operating

systems in this space can provide for that, such as RIOT [

] or

FreeRTOS [

] and others [

]. These can run on the bulk of commod-

ity microcontroller hardware available. Note that RTOS facilities

for scheduling enable simple controlling of how Femto-Containers

interfere with other tasks in the embedded system.

No Assumptions on Microcontroller Hardware.

To retain

generality, we aim for a purely software-based isolation, which

can also run on the least capable microcontrollers, without any

assumptions on hardware architecture enhancements or security

文档加载中……请稍候！
如果长时间未打开，您也可以点击刷新试试。

下载文档到电脑，查找使用更方便

10 玖币 0人已下载

立即下载

摘要：

Femto-Containers:LightweightVirtualizationandFaultIsolationForSmallSoftwareFunctionsonLow-PowerIoTMicrocontrollersKoenZandbergInriaFranceEmmanuelBaccelliInriaFranceFreieUniversitätBerlinGermanyShenghaoYuanInriaFranceFrédéricBessonInriaFranceJean-PierreTalpinInriaFranceABSTRACTLow-poweroperatingsyste...

展开>> 收起<<

Femto-Containers Lightweight Virtualization and Fault Isolation For Small Software Functions on Low-Power IoT Microcontrollers_2.pdf

共12页,预览3页

还剩页未读，继续阅读

声明：本站为文档C2C交易模式，即用户上传的文档直接被用户下载，本站只是中间服务平台，本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私，请立即通知玖贝云文库，我们立即给予删除！

Femto-Containers Lightweight Virtualization and Fault Isolation For Small Software Functions on Low-Power IoT Microcontrollers_2

相关推荐

开通VIP享超值会员特权

作者详情

相关内容

热门标签

举报选择: