WebAssembly’s Wasmtime 1.0 Revamps Security, Performance
The WebAssembly runtime Wasmtime version 1.0 has been released, with updates to improve the Wasmtime’s security posture and performance. It’s an update that’s been a year in the making.
One reason for the update is that platform developers were bringing WebAssembly outside the browser. That meant it was also outside the sandboxed environment of the browser, said Lin Clark, a senior principal software engineer with Fastly and chair of the WebAssembly System Interface (WASI) subgroup with the Byte Code Alliance. The alliance is an open source consortium dedicated to building on standards such as WebAssembly and WASI. Mozilla, Fastly, Intel, and Red Hat are founding members.
Use cases outside the browser are where the runtime comes into play, allowing WebAssembly to run safely outside the browser, Clark noted in a blog post about the new release.
“They were … thinking that you would just download WebAssembly code, run it on your computer with full permissions to the file system, and that’s just super dangerous,” Lin told The New Stack Thursday ahead of the release. “So that’s one of the reasons why we started Byte Code Alliance — to make sure as WebAssembly moves from in the browser use cases to outside the browser use cases, we’re ensuring that we keep that strong security.”
Improved Performance in the Runtime
The Byte Code Alliance has seen improved performance results across companies that have tested the new runtime. A few examples Clark highlighted in her post and with TNS:
- Shopify switched to Wasmtime in July of last year and saw an average execution performance improvement of approximately 50%.
- Fastly switched to Wasmtime in March of this year and saw about a 50% improvement in execution time, as well as a 72% to 163% increase in eqests-per-second that it could serve.
- DFINITY launched its blockchain using Wasmtime in May 2021 and in the year since has executed over 1 quintillion instructions for over 150,000 smart contracts without any production issues.
In a post on how the alliance achieved the performance improvements, Fastly software engineer and Byte Code Alliance member Chris Fallin explained a bit about how it worked and how they focused on optimizing both the runtime and the compiler.
“When Wasmtime executes a Wasm program, the CPU executes both native instructions that have been compiled from the Wasm bytecode, and parts of the ‘Wasmtime runtime,’ which is the part of Wasmtime that maintains data structures to help implement Wasm semantics,” he said. “For each of these two halves of the execution, there are two phases: startup/initialization (compilation of Wasm code, and initialization of runtime), and steady-state execution.”
To improve the speed, the team focused on optimizing each phase, specifically the:
- Time to compile the code in Cranelift, the alliance’s compiler.
- Speed of generated code in Cranelift.
- Time to instantiate a Wasm module in Wasmtime.
- Speed of runtime primitives in Wasmtime.
Security in Wasm
One thing that makes WebAssembly both secure and fast is the isolation between incidents. Each Wasm module gets its own state and can’t affect the state of others, explained in a Byte Code Alliance article by Nick Fitzgerald detailing the security updates.
That makes it safe to run an untrusted WebAssembly program because programs “can’t read or write external regions of memory, transfer control to arbitrary code in the process, or freely access the network and filesystem,” the article noted. The program can’t escape the sandbox to steal private data from other systems or run a botnet on servers.
“But these security properties only hold true if the WebAssembly runtime’s implementation is correct,” the article warned.
Wasmtime is implemented in Rust, which helps it avoid a “whole class of bugs without sacrificing the low-level control we need to efficiently implement a language runtime,” the piece stated. However, Rust doesn’t spare Wasmtime from other problems, such as “miscompilations due to logic errors” in the compiler that could escape from the sandbox.
The rest of the post is dedicated to explaining how the new update addresses those bugs through:
- Using cargo vet, a Mozilla-created tool that ensures all third-party Rust libraries used inside Firefox have been manually reviewed by a trusted auditor.
- Providing isolation between tasks so a bug can’t automatically infect all other subsequent tasks, which is a possible because Wasmtime’s fast instantiation.
- Continuous fuzzing. “Fuzzing is a software testing technique used to find security and correctness issues by feeding pseudo-random data as input into the system you’re testing,” the article noted. ”We do continuous fuzzing in the background, 24/7.” It goes on to explain all the ways the alliance has embraced “fuzz-driven development.”
- Formal verification of Wasmtime and Cranelift.
- Steps to mitigate Spectre attacks.
Use Cases for WebAssembly
WebAssembly’s benefits and uses typically fall into four areas, Clark said. First, it’s fast. While virtual machines, containers or JavaScript isolate can perform some of the same startup and teardown, WebAssembly can do so faster, Clark said. Fastly uses WebAssembly to run serverless functions for the edge, for example.
“A JavaScript isolate is the fastest of all of those and it takes five milliseconds to start up a JavaScript isolate as compared to five microseconds with a WebAssembly instance,” Clark told TNS. “You can just go orders of magnitude faster start-up and teardown with WebAssembly.”
WebAssembly also gives developers language neutrality since it enables developers to run lots of different kinds of languages in a serverless function, Clark said.
WebAssembly can also be used in databases, analytics, and event stream use cases.
“When you have a database And you have a lot of communication between the code and the data, going back and forth, you do a query, you get some data over to the code, and then the code processes it and then asks the database for more data based on the results of that, and it just keeps going back and forth, back and forth, and back and forth,” Clark said. “It’s a lot faster if you just have this processing code running inside of the database itself… but you can’t do that if you don’t have safety guarantees. WebAssembly can give you those safety guarantees within running in the database.”
Another, similar use for WebAssembly is with third-party plugin systems, she added, pointing to Shopify’s use with commerce as one example.
“Before, Shopify would basically have this plugin running outside of the main Shopify codebase and there was a lot of latency and it was crashing when they had flash sales,” Clark explained. “They’re using WebAssembly to run that third party code inside of the code base so that they’re able to keep that latency super short and scale to whatever they need without risking the security of the user flow.”
Two more niche use cases are portable clients such as the BBC’s iPlayer, and Trusted Execution Environment, which is used in high-security situations.
