WebAssembly is the standard technology to accelerate web-based applications that need to perform computeintensive workloads. Lower-level languages such aCs, C++, and Rust can be used to implement functionalities that are executed by user agents, providing an alternative to JavaScript for performance-critical tasks. In this domain, safety and portability are key aspects: the former is essential to protect users from malicious modules while the latter enables having the exact same WebAssembly code to run seamlessly across browsers, operating systems and hardware architectures.
The swift expansion of the Internet of Things ( IoT) and advancements in embedded devices have
underscored the growing need for secure and portable software solutions across diverse environments.
By 2030, the number of embedded systems worldwide is expected to surpass 25 billion [
WebAssembly ( Wasm), originally designed to enhance the performance of Web applications, has emerged as a promising technology to address the challenges of a fragmented compute ecosystem. Its portable binary instruction format and sandboxed execution model make it a valid option for devices with heterogeneous architectures that require a robust security model. By abstracting platform-specific details through a virtual machine,Wasm enables applications to run consistently across diferent environments, from browsers to standalone runtimes. However, the transition ofWasm from Web environments to embedded systems introduces new challenges, particularly in achieving seamless cross-platform portability and ensuring safety in resource-constrained devices.
This research aims to explore the benefits and challenges of adopting Wasm in embedded environments, focusing on two critical aspects: safety and portability. Specifically, it investigates how Wasm’s safety features can enhance memory isolation in systems lacking hardware memory protection
CEUR
ceur-ws.org and evaluates whether its portability promises hold in embedded contexts. Furthermore, it addresses challenges such as the lack of native support for access to hardware resources and proposes potential solutions, including Hardware Abstraction LayersH(ALs).
To address theWasm portability challenges outside of Web environments, the WebAssembly System Interface (WASI) was introduced as an extension to enhanceWasm’s applicability beyond the browser. WASI defines a standardized set of APIs for system-level operations, such as file I/O, networking, and time management, aiming to provide a consistent interface forWasm applications across cloud, desktop, and edge environments. Despite its potential, the applicability ofWASI to embedded systems remains limited. Embedded devices often lack full-fledged operating systems and require low-level access to hardware resources, such asGPIOs and peripherals, whichWASI does not natively support.
The remainder of this paper is structured as follows. Section 2 analyzes the core principles of Wasm, focusing on its safety mechanisms and portability features. Section 3 examines the unique challenges faced by embedded systems, with a focus on security and cross-platform execution. Section 4 investigates the integration ofWasm in embedded systems, analyzing runtime implementations and emerging solutions for hardware abstraction. Section 5 discusses open challenges in the evolution of Wasm, particularly in the context of embedded applications.
Wasm combines robust safety guarantees with broad portability features, making it well-suited for heterogeneous computing environments. Its sandboxed execution model ensures that code runs securely within strict boundaries, while its platform-agnostic design enables consistent execution across heterogeneous hardware architectures and operating systems. These complementary attributes form the foundation of WebAssembly’s design philosophy, addressing security and cross-platform compatibility as core concerns rather than afterthoughts.
The fundamental deployment and execution unit is aWasm module, that can be represented in both a
human-readable text format (WAT) [
Figure 1 illustrates howWasm operates, highlighting both its internal memory model and its integration within a broader application environment 4[]. It shows howWasm executes code and interacts with other system components.
The Wasm memory model, shown in Figure 1a, consists of distinct memory regions. The operand stack is explicitly managed usingWasm instructions and serves as temporary storage for intermediate computations. MostWasm instructions interact with this stack in some way. For example, instructions such as local.get and i32.const push values onto the stack. Arithmetic and logical instructions (i32.add, f64.mul, i32.and) take their operands from the stack and push the result back onto it.
Separately,Wasm maintains an internal shadow stack, which is managed by the runtime and used to track function calls, return addresses, and local variables. Unlike the operand stack, the shadow stack is not accessible toWasm code, ensuring control-flow integrity by preventing direct manipulation of return addresses.
The linear memory is a contiguous, byte-addressable region that is entirely separate from the operand stack and serves as the primary data storage foWrasm programs. Unlike the operand stack, which is automatically managed, linear memory must be explicitly allocated and resized by theWasm module
Lmineema_rsMizeemory
0 0x8F00 0x91AA 0x5C41 0x7F12 Call 2 0x5C41
Push
Pop mem_size Stack (a) Diagram of the Wasm memory model illustrating the interactions between the operand stack, linear memory, and instruction execution. The operand stack handles intermediate computations, the linear memory serves as the primary data storage, and the instruction execution manages operations on these components.
E x p o s e d F u n c it o n s
E x p o s e d F u n c it o n s JS
WA
Linear Memory
Runtime (Browser, Node.js, ...) (b) Architecture of a typicalWasm application demonstrating the integration between Wasm modules and JavaScript within a managed execution environment, such as a browser or Node.js. using instructions such asmemory.grow. Instructions like i32.load, i32.store, and memory.fill allow Wasm modules to read from and write to linear memory, providing a structured approach to data storage.
Figure 1b illustrates the design of a typical application integratinWgasm with JavaScript. TheWasm module runs within a managed execution environment, such as a browser or Node.js, where it interacts with JavaScript through function calls and a shared linear memory space. While this shared memory enables eficient data exchange between Wasm and JavaScript, it also requires careful management to prevent unintended access or memory safety violations. The interaction between the two is strictly controlled, with Wasm exposing only explicitly defined functions, reducing the risk of unauthorized memory access or corruption, as the shared memory is separated from the host’s memory. This mechanism allows Wasm to integrate with WebAPIs, event-driven architectures, and external resources while preserving the security guarantees of the execution environment.
This architecture ensures a balance between performance and safety. The sandboxed design isolates
Wasm modules while enabling eficient communication with host environments through shared linear
memory and exposed function interfaces.
2.1. Safety
Wasm’s security model is designed with a multi-layered approach that protects users from potentially
buggy or malicious modules while providing developers with powerful primitives for creating secure
applications. At its core,Wasm represents a carefully designed typed assembly language 5[] that
enforces strict safety guarantees through a combination of static validation and runtime mechanisms.
Sandboxing Wasm modules operate within a sandboxed environment that employs fault isolation
techniques to prevent applications from directly interacting with the host system. This isolation
ensures that modules execute independently and cannot access system resources without going through
controlled APIs [
Static Validation and Type Safety Before execution, the Wasm modules undergo a comprehensive
validation to ensure conformity with theWasm specification. The specification explicitly requires
that allWasm code must be validated to guarantee safe execution8[]. Wasm modules must explicitly
declare all accessible functions along with their associated types, ensuring that functions and their
parameters are well-defined and type-checked before execution. Unlike most native architectures, Wasm
enforces a strong typing system for all globals, locals, and function arguments and results. This static
type-checking prevents type confusion vulnerabilities and ensures the integrity of function calls [
Data Execution Prevention Wasm enforces Data Execution Prevention D(EP) by strictly separating
executable code from writable memory. The linear memory space is never executable, preventing
code injection attacks. Additionally,Wasm code itself is stored in an immutable, read-only section
inaccessible to the application, meaning that an attacker cannot overwrite existing instructions or
introduce new executable code at runtime. This design makes common exploitation techniques such as
shellcode injection, just-in-time spraying, and self-modifying code attacks infeasible.
Structured Control Flow Instructions within a function are organized into well-defined nested
blocks, with branching operations restricted to jumps to the end of surrounding blocks within the same
function. This strict control prevents jumps to arbitrary addresses and disallows the use of unstructured
goto statements [
Shadow Stack Protection Wasm enhances control-flow security by employing a shadow stack,
managed by the Wasm virtual machine and containing return addresses and local variables. Unlike
native execution environments where return addresses are stored directly on the program’s stack,
Wasm’s shadow stack is inaccessible to the executing module, preventing adversaries from modifying
return addresses to hijack control flow. This mitigates common attack techniques such as return address
corruption andROP, which rely on tampering with saved return addresses to execute arbitrary code.
By enforcing an immutable call-return discipline, the shadow stack significantly strengthens Wasm’s
control-flow integrity ( CFI) [
Statically verifies that a module conforms to the Wasm Execution of malformed or malispecification before execution, ensuring that all operations cious binaries, undefined behavare well-formed and type-safe. ior, type confusion attacks.
Enforces strict typing for function calls, memory accesses, Type confusion vulnerabilities,
and data, ensuring that operations adhere to declared improper memory accesses,
types [
Enforces separation between the operand stack and linear Stack smashing, arbitrary memmemory, preventing direct corruption of execution state. ory corruption, control data overwrite.
Enforces structured control flow by restricting branches Control-flow hijacking,
arbito valid targets within well-defined blocks [
Maintains an internal, inaccessible stack for storing return Return address corruption, ROP addresses and call metadata, preventing tampering with attacks, call stack manipulation. the call/return sequence.
Ensures linear memory is never executable and code sec- Code injection, shellcode exetions are immutable, preventing the execution of injected cution, self-modifying code atcode. tacks. edge computing platforms, and embedded systems with minimal changes to its core specification, demonstrating its remarkable portability.
At its foundation,Wasm achieves portability through a carefully designed stack-based virtual machine architecture. This approach enables developers to compile code from languages likCe, C++, and Rust into Wasm modules that can execute wherever a compatible runtime exists, eliminating the need to tailor applications for each target environment. By providing a consistent runtime environmentW,asm ensures that applications behave predictably regardless of the underlying platform. Well-defined Specification The specification outlines a well-defined module structure organized into various sections, including type declarations, imports, exports, and code definitions. This standardized structure ensures thatWasm modules can be reliably interpreted across diferent environments. Wasm provides a compact, well-defined instruction set that includes operations for arithmetic, control lfow, memory access, and function calls. The limited and precisely specified instruction set contributes to consistent execution behavior across platforms. The specification includes a rigorous type system with basic scalar types such as integers and floating-point numbers, along with a type-checking algorithm that ensures type safety. This type-checking helps prevent platform-specific behaviors that could compromise portability.
Canonical Execution Environment The Wasm specification assumes that execution environments
ofer characteristics such as 8-bit wide bytes, single byte memory addressing granularity, support for
unaligned memory accesses, two’s complement integers, IEEE 754 floating point numbers, little endian
byte ordering, lock-free atomic operations on 8, 16 and 32-bit values and secure isolation between
Wasm modules. Platforms that do not natively provide these capabilities can still executWeasm code by
having the virtual machine emulate the required behavior, although this may impact performance 1[
Host Environment Integration Wasm achieves portability while still allowing interaction with host
environments through a controlled mechanism known as embedding [
Limitations of WebAssembly The core Wasm specification intentionally omits built-in system
calls and common interfaces for accessing underlying system resources such as file systems, network
interfaces, or hardware peripherals 1[
Market pressures compound these technical limitations. Manufacturers prioritize producing
featurerich chips at minimal cost, often neglecting long-term security and maintenance considerations. This
economic model creates little incentive to update older devices once deployed, leaving them vulnerable
to emerging threats. Even newly deployed embedded systems frequently run software several years
behind current versions, and available security patches are seldom applied [
Programming errors constitute the primary source of vulnerabilities in embedded systems, typically
exploited through bufer overflows or malicious input injection. Weak access control mechanisms
frequently fail to properly authenticate users or enforce secure access policies, creating opportunities for
privilege escalation or impersonation attacks. Additionally, implementation errors in protocol handling
represent another common vulnerability source, more prevalent than design flaws in the protocols
themselves [
Embedded systems present unique portability challenges due to their diverse operating environments. Many devices operate without general-purpose operating systems, instead relying on bare-metal programming or lightweight real-time operating systems (RTOS). This diversity requires developers to interact directly with varied hardware components across diferent devices and manufacturers, significantly complicating the development process.
HALs partially address these portability challenges by providing standardized interfaces for hardware
resource access [
The fundamental portability challenge lies in balancing abstraction with performance. WhilHe ALs abstract certain functionalities, underlying configurations remain tied to specific hardware architectures. For example, common peripherals like UART or I2C exist across devices, but their initialization and configuration vary significantly due to diferences in interrupt handling, clock gating, and direct memory access capabilities. This variance means that while application code may be portable, thHeAL itself often requires substantial adaptation between platforms.
Vendor-provided HALs frequently lead to vendor lock-in, making platform migration costly and
time-consuming. The embedded-hal Rust project [
Embedded systems present unique challenges for software deployment due to their resource constraints, diverse hardware architectures, and critical safety requirements. These systems traditionally rely on native code compiled specifically for their target platforms, creating significant barriers to software portability. Wasm, originally designed for browser environments, ofers promising capabilities for these specialized computing contexts by providing a secure execution model.
The potential appeal ofWasm for embedded development lies in its ability to address two fundamental challenges in the field. First, its sandboxed execution model provides valuable security guarantees. Second, its binary format and virtual machine architecture ofer a path toward greater code portability across the fragmented landscape of embedded hardware. While these benefits align well with embedded systems requirements, the introduction of Wasm into this domain requires navigating significant technical constraints and standards gaps that difer from those encountered in web or server environments. 4.1. Safe Execution of WebAssembly in Embedded Systems In embedded environments, security is not just about protecting data: it is about ensuring the correct operation of critical system functions. Many embedded devices lack hardware-based security measures such as memory management units that provide memory isolation and protection, making softwarebased security mechanisms especially important.
Wasm’s sandboxed execution model addresses these concerns by providing strong isolation between untrusted code and core system components. This isolation is particularly valuable for embedded devices that may support dynamic updates or third-party modules. EachWasm module undergoes static validation before execution, and its program code can’t change after being loaded. This design prevents runtime modifications or code injection attacks, ensuring that even if a module is compromised, the attack remains contained and cannot alter the system’s fundamental behavior.
By requiring modules to declare all imported and exported functions,Wasm enforces fine-grained control over which parts of the system can be accessed. This mechanism is particularly important in embedded devices, where direct access to peripherals or sensor data must be carefully restricted. The explicit boundaries help ensure that only validated, authorized code can interact with critical hardware, reducing the risk of unauthorized control or exploitation.
The security benefits of Wasm in embedded systems do come with trade-ofs. The virtual machine introduces additional overhead for resource allocation, context switching, and isolated memory management. In resource-constrained environments, this can lead to reduced execution eficiency and increased power consumption—exchanging some performance for enhanced security. These trade-ofs must be carefully evaluated based on the specific requirements of each embedded application. 4.2. Challenges in Embedded WebAssembly Deployment While Wasm provides a portable execution environment for computational logic, its application in embedded systems faces significant challenges that go beyond those encountered in general-purpose computing environments.
A fundamental limitation is Wasm’s lack of standardized interfaces for hardware access. Embedded systems often require direct, low-level access to hardware resources such as GPIO pins, UART interfaces, sensors, and actuators. The currentWasm specification does not provide native mechanisms for interacting with such hardware peripherals. This gap means that while the core computational aspects of applications can be portable, the hardware interaction layer remains platform-specific.
The adoption ofWASI has begun to address similar challenges in general-purpose computing environments by standardizingAPIs for file I/O, networking, time management, and random number generation. However,WASI was designed with the assumption that the host environment includes an operating system providing these standard services; such an assumption that doesn’t hold for many embedded systems that operate without a full-fledged OS.
Eforts to extend WASI for embedded-specific needs are still emerging. Interfaces for common
embedded protocols like I2C and SPI are under development but remain in early proposal stages2[
Projects like Embedded WASM [
This paper has examinedWasm’s potential and limitations in embedded systems contexts. Wasm ofers significant benefits for embedded applications, particularly through its inherent security features like sandboxing and isolation. These capabilities are especially valuable in embedded environments where hardware-based memory protection is typically unavailable due to the absence of virtual memory systems. Despite being originally designed for web browsers,Wasm’s architecture has demonstrated remarkable adaptability, enabling its deployment across vastly diferent computing environments from desktop systems to cloud infrastructure and resource-constrained embedded devices.
However, our analysis reveals thaWtasm falls short of achieving true “write once, run everywhere” portability in embedded contexts. While the specification successfully defines a virtual instruction set architecture and execution model, it deliberately avoids standardizing how modules interact with host resources. This design choice, which enables flexibility across diverse platforms, simultaneously creates significant challenges for embedded applications that require consistent hardware access. The import/export mechanism provides the technical foundation for host interaction, but without standardized interfaces, true portability remains elusive.
This limitation becomes particularly evident when comparingWasm’s usage patterns across diferent environments. In web applications,Wasm typically serves as an acceleration mechanism for computeintensive tasks within a JavaScript-driven application, requiring only limited host system interaction. By contrast, standaloneWasm applications require comprehensive system interfaces comparable toPOSIX APIs to support real-world functionality. TheWASI proposal by theW3C WebAssembly Community Group attempts to address this gap by providing standardizedAPIs for application development.
Yet WASI’s current specification primarily targets desktop and cloud environments, ofering limited value for embedded systems that operate without an underlying operating system. In such environments, conventional operations like filesystem access or socket communication may be entirely irrelevant. The emerging eforts to extend WASI with embedded-specific interfaces for protocols like GPIO, SPI, and I2C represent promising developments, but these standards remain in early stages and insuficient for comprehensive embedded deployment.
The diversity of embedded hardware presents additional challenges beyond interface standardization. Embedded devices vary significantly across manufacturers and even within product families, necessitating customized initialization code for microcontrollers and peripherals. To mitigate this challenge, we propose architectural approaches that strongly decouple business logic from hardware-specific implementation, allowing for targeted customization while preserving application portability. Furthermore, the development of lightweight, modular runtime environments specifically optimized for embedded workloads could significantly improve both performance and portability in resource-constrained contexts.
By addressing these technical and standardization challengesW,asm could emerge as a transformative technology for embedded systems development, enabling more secure, portable, and eficient applications. Such advancement would be particularly valuable for meeting the evolving requirements of IoT and edge computing ecosystems, where secure code execution and cross-device deployment represent persistent challenges. The continued evolution ofWasm standards, particularly those focused on embedded-specific requirements, will largely determine whether this promising technology can fulfill its potential in the embedded systems domain.
Declaration on Generative AI: The author(s) have not employed any Generative AI tools.
Funding: This work was partially supported by the MUR National Recovery and Resilience Plan funded by the European Union – NextGenerationEU through Project “SERICS – Security and Rights in CyberSpace” under Grant PE00000014.