WasmCon 2024

What’s the smallest possible footprint for a WebAssembly application on an embedded device? This talk aims to answer just that. Wasm has some great advantages, including its polyglot nature: the ability to compile multiple languages to the same target, allowing developers unfamiliar with embedded C to program tiny devices, and dynamically load applications on target devices. But this comes at a cost: the footprint of the runtime and the overhead of our chosen languages. What if we could reduce this overhead to the bare minimum? A less-well-known but valuable Wasm feature is that (unlike with Java, JavaScript, Python, etc.) Wasm’s “runtime” can be extraordinarily minimal—almost zero in size. Join as we demonstrate how to make a Wasm runtime“limbo dance”, reducing its overhead to under 5 kilobytes of ROM and a few hundreds of bytes of RAM, and even lower still with some sacrifices.

The `wasm-tools` project contains the underpinnings of Wasmtime's processing of WebAssembly binaries, but it also provides a CLI tool with a rich suite of subcommands for working with WebAssembly files. Come learn about how `wasm-tools` can help you explore and manipulate WebAssembly binaries as well as helping you debug, fuzz, inspect, and test your next wasm project.

Debugging and profiling programs is done through instrumenting the program-under-observation (inserting instructions to monitor dynamic execution). The most-common techniques inject instructions directly into the program. While this enables tools to support any domain, it intrudes on the program state space, complicates the implementation, limits the scope of observation, and cannot dynamically adapt. These issues can be remedied by interfacing with an engine, like Wizard, with instrumentation support. A recent ASPLOS paper demonstrated how to build support that protects the application, provides consistency guarantees, applies JIT optimizations, and more. However, this technique limits a tool's scope to programs that can run on such engines. This talk presents the design of a new instrumentation DSL for Wasm that abstracts above the injection technique enabling tooling to support a wide domain of applications while leveraging runtime capabilities as-available without reimplementation.

One of the most beloved features of the component model is extensibility. As the WebAssembly ecosystem continues to grow, the WebAssembly community will need extensibility beyond component composition to build everything from plugins to fully distributed microservices and everything in between. This is where wRPC (WIT-RPC), a WebAssembly component-native, transport-agnostic RPC protocol and framework comes in. wRPC facilitates WIT (WebAssembly Interface Type) defined composition over network, IPC, or other means of communication. What this means is every WebAssembly component can be used with wRPC out-of-the-box using your execution model of choice. This talk will discuss why wRPC exists, the design behind it, and how you can integrate it with your WebAssembly runtimes and platforms. Through many diagrams and demos, you’ll learn why wRPC is important and how it can be used to create reusable, language-agnostic plugins and distributed component communication.

WebAssembly offers a lot of advantages for IoT and embedded development: developers can use modern toolchains, diverse programming languages and sandboxing technology on truly tiny devices like ESP32 microcontrollers. Support for these use-cases is improving with the newly formed Embedded SIG and new interfaces for connecting WebAssembly applications to underlying hardware via USB and I2C. This talk explains how WebAssembly improves embedded development and shows how to control connected USB and I2C devices from WebAssembly. It covers the WASI-USB and WASI-I2C proposals and explains how to embed a device driver in WebAssembly. The session also takes a look at the overhead of these interfaces and embedded WebAssembly in general. The session closes with a peek into the future.