Fast, Scalable, Secure: WebAssembly and the Future of Isolation

WebAssembly (Wasm) as an Isolation Technology

• The speaker, T Garfinkle, introduces WebAssembly (Wasm) as an isolation technology and explains its potential applications in security, stability, and serverless computing.
• He draws a parallel between Wasm and virtualization, highlighting how both technologies use software to overcome hardware limitations.

Isolation Approaches

• Garfinkle discusses two main approaches to isolation: hardware-based isolation (using page tables and protection rings) and software-based fault isolation (SFI).
• Hardware-based isolation, while offering language independence and bare metal speed, is relatively coarse-grained, slow to start, and resource-intensive.
• SFI, on the other hand, is language-dependent but offers fine-grained control, fast startup times, and a small footprint.
• Wasm is based on SFI, leveraging the compiler to enforce protection instead of relying solely on hardware.

WebAssembly: A Unique Approach to Isolation

• Garfinkle emphasizes that Wasm occupies a distinct space in the design landscape, offering a unique approach to isolation compared to containers and virtual machines.
• WebAssembly is a platform-independent intermediate representation (IR) that can be ahead-of-time (AOT) or just-in-time (JIT) compiled.
• It isolates components within a single address space, typically within a single operating system process.

WebAssembly's Origins and Adoption

• WebAssembly started as a web standard and has gained support from major browsers.
• It is now being adopted for edge computing and other applications.

WebAssembly Use Cases

• One example of WebAssembly's use is library sandboxing, where it isolates buggy libraries to prevent vulnerabilities from compromising the entire application.
• Firefox uses WebAssembly to sandbox libraries, preventing vulnerabilities from affecting the browser's renderer.
• This approach is applicable to any application that relies on C or C++ libraries, as these languages are prone to bugs.
• Research is ongoing to make WebAssembly sandboxing more accessible to developers, allowing them to opt into sandboxed versions of libraries.
• Another significant use case for WebAssembly is serverless computing, where it enables hyperscaling on edge platforms.

WebAssembly: Advantages and Limitations

• WebAssembly (Wasm) is a lightweight isolation technology that allows for running code in a secure and isolated environment.
• Wasm is used in various applications, including server-side code execution, plugin development, and Internet of Things (IoT) devices.
• Wasm offers advantages over traditional virtual machines (VMs) in terms of memory usage, startup time, and scalability.
• Wasm's platform independence makes it suitable for developing applications that can run on diverse devices.
• While Wasm offers significant benefits, it also has limitations, including performance overheads and scaling challenges.

Scaling Limitations of WebAssembly

• WebAssembly (Wasm) faces scaling limitations when running in a serverless context. The high number of instances needed for fast response times can lead to address space exhaustion and performance bottlenecks due to context switching and inter-process communication (IPC) overheads.
• The Wasm component model, which allows applications to be broken down into isolated components, can exacerbate the scaling problem by increasing the number of address spaces needed.

Compatibility Issues with WebAssembly

• Wasm's compatibility with programming languages and compilers is a significant limitation. The interface needs to be rich enough to support the features of various languages and exploit hardware functionality. Dynamic code generation, direct system calls, and platform-specific assembly are not currently supported.

Hardware Optimizations for WebAssembly

• Two optimizations, Segue and Color Guard, are being used to improve Wasm performance. Segue reduces Wasm's total tax by 25%, while Color Guard addresses the scalability problem, allowing for a significant increase in the number of instances.
• The removal of segmentation in x86-64 architecture has limited the use of segment registers. However, these registers can be repurposed for other purposes, such as thread local storage. This opens up possibilities for using segment registers to improve Wasm performance.

Base Edition and Color Guard: Performance Enhancements

• The text discusses two techniques used to improve the performance and scalability of WebAssembly (Wasm) runtime environments: Base Edition and Color Guard.
• Base Edition optimizes memory access by using segment registers instead of general-purpose registers, reducing instruction cache pressure and code size. This technique has been implemented in Intel's Wasm runtime compiler and runtime, "Whammer," resulting in faster compilation times.
• Color Guard leverages memory protection keys (MPK) available on Intel and AMD processors to create color-based memory protection. Each page of memory is assigned a 4-bit tag (color), and each core has a tag register. Access to a page is allowed only if the color in the register matches the color of the page.
• Color Guard allows for more efficient use of memory by eliminating the need for large guard regions, enabling the execution of significantly more Wasm instances in the same amount of space.
• Despite these improvements, the text acknowledges that limitations remain, such as the restricted number of colors (15) and the fixed memory size (8 GB).

Hardware Support for WebAssembly

• The text then highlights the need for hardware support to further enhance Wasm performance and scalability.
• Three key requirements for this hardware support are:
  • Simple microarchitecture: Minimizing the complexity of the hardware design to make it easier to implement.
  • Minimal OS changes: Avoiding the need for significant modifications to operating systems like Linux and Windows.
  • Support for both Wasm and other isolation techniques: Enabling the use of Wasm alongside other software-based and compiler-enforced isolation mechanisms.

Hardware Assisted Fault Isolation (HFI)

• The text discusses a new technology called Hardware Assisted Fault Isolation (HFI) which is a user-space ISA extension that provides fast and scalable isolation for code execution.
• HFI uses "bases and bounds" to define memory regions that a sandboxed program can access. This allows for fast memory access checks that are performed in parallel with TLB lookups, adding no overhead to native code execution.
• HFI also enables fast physical interposition, which is a technique for intercepting memory accesses and can be used for security features like Spectre mitigation.
• HFI offers unlimited scaling, meaning it can handle a large number of sandboxes without performance degradation. It also has a small amount of state, making it easy to set up, tear down, and resize sandboxes quickly.
• HFI is compatible with existing code, meaning it doesn't require changes to the code being sandboxed.

Addressing Challenges in Implementing HFI

• The text then discusses the challenges of implementing HFI in hardware, specifically the limited gate count and the need to avoid slowing down existing pipeline stages.
• To address these challenges, HFI uses specialized regions with different types of addressing:
  • Explicit regions: These regions use relative addressing and require only one 32-bit comparison for memory access checks. This is suitable for smaller regions where relative addressing is sufficient.
  • Byte granular regions: These regions provide byte-level granularity for memory access checks, allowing for sandboxing of existing code without modifications. This is important for sandboxing libraries and other components that rely on specific memory layouts.

Importance of Byte Granular Regions for WebAssembly

• The text concludes by highlighting the importance of byte granular regions for sandboxing WebAssembly (Wasm) code, which often uses multiple linear memories and requires fine-grained memory control.

Benefits of Hardware-based Fine-grained Isolation (HFI)

• The speaker discusses the benefits of using Hardware-based Fine-grained Isolation (HFI) for memory management in WebAssembly (Wasm) and other applications.
• HFI allows for efficient memory allocation in 64k chunks, enabling the use of the same memory region for code, static data, and the stack.
• HFI simplifies system call interposition by allowing for a direct jump back to the runtime instead of relying on complex mechanisms like kernel modifications or library interposition.
• HFI provides Spectre-safe bounce checks, ensuring that memory access is never speculative beyond the bounds of the sandbox.
• The speaker acknowledges that Spectre is a complex issue with no easy solution, but HFI helps mitigate the risk by preventing speculative memory access outside the sandbox.

Performance and Scaling Advantages of HFI

• HFI offers performance benefits, particularly for 64-bit memories, and provides advantages in terms of scaling, Spectre resistance, and smaller address spaces.
• The speaker highlights the use of HFI in applications like image rendering and Firefox, where it has resulted in significant performance improvements.

Versatility of HFI

• The speaker emphasizes that HFI is a versatile technology that can be applied to both Wasm and native binaries, offering a unified approach to isolation.
• The speaker acknowledges that while HFI is well-suited for collaborative workflows where function calls are predictable, it may require a scheduler for scenarios with more dynamic interactions between applications.

Concurrency Support in WebAssembly

• The speaker addresses the question of resource isolation in WebAssembly (Wasm) and explains that while Wasm provides address spaces and isolation, concurrency is not part of the standard.
• The speaker mentions that Wasm runtimes like Fastly and Tokyo use libraries like Tokyo to handle concurrency and preemption.
• The speaker discusses the recent release of the WX runtime and its implications for multi-threaded Wasm applications.
• The speaker explains that there are two aspects to threading support: atomics and thread creation.
• The speaker highlights the Wy Threads proposal, which provides a way to create threads in Wasm, and its impact on the development of threading standards.
• The speaker acknowledges that the Wy Threads proposal has limitations but emphasizes its role in driving progress towards a more robust threading solution.
• The speaker discusses the challenges of sharing resources between threads in a Wasm context, particularly in relation to linear memory, tables, and safe sharing.
• The speaker concludes that threading support in Wasm is evolving and that while there are still challenges, the ecosystem is actively working towards better solutions.

Optimizations for ARM Architectures

• The speaker addresses a question about optimizations for ARM architectures, specifically mentioning the absence of segmentation in ARM and the potential use of memory tagging extensions in ARM v9 for memory isolation.
• The speaker mentions that there is no RV9 hardware available except for in some mobile phones, specifically the third generation Amper devices.

Toolchains for WebAssembly Development

• The speaker recommends two toolchains for working with WebAssembly: Wasm Time and Wy Kang.
• Wasm Time is well-supported and considered secure, while Wy Kang is good for C/C++ development.

Getting Started with WebAssembly

• The speaker suggests that having a project or need can provide motivation for learning WebAssembly.
• The speaker highlights the supportive WebAssembly community, particularly the Bytecode Alliance on Zulip, where users can ask technical questions.
• The speaker encourages those interested in secure sandboxing of native code to reach out to them.