WebAssembly + Zephyr: A Two-Layer Isolation Model for Embedded Systems

Why Combine Zephyr with WebAssembly?

Embedded devices often face a difficult trade-off. The core firmware must remain stable, while application logic may need to change more frequently.

Combining Zephyr User Mode with WebAssembly provides a lightweight way to add flexible application logic without exposing the core system to unnecessary risk. Together, they enable a practical architecture that separates platform firmware from updateable application logic.

Zephyr User Mode

Zephyr User Mode provides hardware-backed isolation between application code and the operating system.

User code runs with restricted access to memory and kernel resources. User threads can only access authorized memory regions and approved kernel services. If a user thread performs an illegal memory access, the fault can be contained without bringing down the entire system.

For a WebAssembly-based design, this means the WebAssembly runtime itself can execute inside a Zephyr user thread, creating a protection boundary between the runtime and the rest of the system.

WebAssembly

WebAssembly is a portable binary format designed for safe and efficient execution.

A Wasm module executes inside a sandbox with its own linear memory and cannot directly access host memory. Interaction with the surrounding system occurs only through explicitly exposed host functions.

These characteristics make WebAssembly a good fit for application logic that is:

• Frequently updated
• Developed by multiple teams
• Less trusted than core firmware
• Shared across multiple products

By separating application logic from platform-specific firmware, WebAssembly allows business logic to evolve independently of the underlying system.

WAMR

WebAssembly modules do not run directly on Zephyr. They require a runtime responsible for loading modules, managing execution, validating memory accesses, and providing host-function support.

WebAssembly Micro Runtime (WAMR) is a lightweight WebAssembly runtime designed for resource-constrained systems. WAMR is widely used in embedded environments and provides integration support for Zephyr.

WAMR performs the core runtime functions required to execute Wasm modules while maintaining the sandbox boundary that separates module code from native firmware.

In a typical deployment, WAMR loads and executes Wasm modules, validates accesses to module memory, and enforces the interface between Wasm code and native firmware through host APIs.

A Two-Layer Isolation Model

Together, Zephyr User Mode and WAMR create a two-layer isolation model:

• Zephyr User Mode isolates the runtime thread from the rest of the system.
• The WAMR sandbox isolates Wasm modules running inside that thread.

Application Logic Is Decoupled from Firmware

Business logic can be packaged as Wasm modules. The firmware only needs to expose a stable set of host APIs, allowing application logic to evolve independently from the core firmware.

This separation reduces coupling between application development and firmware release cycles. It also makes it easier to customize products without modifying platform code.

Runtime and System Isolation

The WAMR sandbox does not allow a Wasm module to invoke arbitrary Zephyr services directly.

Instead, all interactions with the operating system must pass through explicitly exposed host APIs implemented by native firmware. This host API boundary limits the set of system capabilities that a module can access and provides a clear interface between Wasm code and the underlying platform.

Host functions execute within the WAMR runtime thread and remain subject to Zephyr User Mode restrictions. Access to kernel services continues to follow Zephyr's userspace model. Operations on kernel objects are performed through system calls, and a user thread may access only those kernel objects for which permission has been explicitly granted.

As a result, even when a Wasm module invokes a host API, access to system resources is still controlled by Zephyr's userspace protection mechanisms. A module cannot bypass the host API boundary, and the runtime thread cannot access kernel objects or privileged resources that have not been authorized.

Memory Isolation

The Wasm sandbox is built on top of memory already assigned to the user-mode runtime thread.

A Wasm module executes within its own linear memory, while the WAMR runtime executes within memory regions that belong to the runtime thread's memory domain. The module cannot directly reference native addresses or arbitrary memory owned by the system.

When the runtime accesses module memory, it does so through validated offsets within the module's linear memory rather than through unrestricted native pointers. This ensures that module memory accesses remain confined to the sandbox.

At the next level, Zephyr User Mode restricts the runtime thread itself to the memory partitions assigned to its memory domain. Any native access outside the authorized memory domain is blocked by the underlying MPU or MMU and handled by Zephyr's userspace protection mechanisms.

Together, the linear-memory sandbox and the user-mode memory domain create a layered memory-isolation model that protects both the runtime and the rest of the system.

Fault Containment

Faults are isolated at multiple levels.

Within the WAMR sandbox, modules execute inside their own linear memory. Invalid memory accesses, runtime exceptions, and other module-level faults can be detected and contained by the runtime. Interaction with the host occurs only through explicitly exposed host APIs.

If a fault occurs in native code running inside the user-mode runtime thread, Zephyr User Mode provides an additional layer of protection by restricting access to authorized memory and kernel resources.

Together, these mechanisms help prevent application-level failures from affecting the kernel or unrelated system components.

WebAssembly vs. Zephyr Loadable Extensions

A natural question is:

Why use WebAssembly instead of Zephyr’s own loadable extension mechanism?

Zephyr supports Loadable Extensions (LLEXT), which allow native code to be loaded into a running system. Both LLEXT and WebAssembly provide a way to extend functionality without rebuilding the entire firmware, but they target different requirements.

Zephyr Loadable Extensions

LLEXT executes native code.

Because extensions run directly on the target system, they can deliver near-native performance and integrate closely with Zephyr services.

However, they are tied to a specific architecture and system configuration, and software defects can have a broader impact on the system.

WebAssembly

WebAssembly executes inside a runtime sandbox.

Instead of directly accessing system resources, modules interact with the system through approved host APIs exposed by the firmware. This introduces some runtime overhead, but it also provides stronger isolation and a portable module format.

Choosing Between Them

In short, LLEXT is often the better choice when the code is trusted and maximum performance is required.

WebAssembly is often the better choice when isolation, portability, and independent updates are the primary goals.

The two approaches are not mutually exclusive. A system can use native code for low-level and time-critical functionality while using WebAssembly for higher-level application logic that benefits from stronger isolation.

Conclusion

WebAssembly is most valuable when application logic needs to be updated independently, developed by different teams, or isolated from the core firmware.

Combined with Zephyr User Mode and a lightweight runtime such as WAMR, it provides a practical balance between flexibility and fault isolation for embedded systems. The runtime executes inside a user-mode thread, while Wasm modules execute inside the runtime sandbox, creating a layered defense against software faults.

The approach comes with costs. Running a Wasm runtime requires additional code space, memory, and execution overhead compared to native execution. Runtime memory, module instances, execution stacks, and Wasm linear memory must all be considered during system design.

WebAssembly is therefore best suited to application logic that benefits from isolation and independent updates rather than hard real-time or hardware-facing functionality.

A useful rule is:

• Keep time-critical and hardware-facing code native.
• Put updateable, less trusted, or product-specific logic in Wasm.

This approach is not a replacement for native firmware. Device drivers, interrupt handlers, and hard real-time control loops should remain native.

For embedded systems that need both flexibility and reliability, the combination of Zephyr User Mode, WAMR, and WebAssembly offers a useful middle ground: more dynamic than fixed firmware, safer than unrestricted native plugins, and practical on resource-constrained devices.