How do you achieve the security guaraties for the content of the .so? Are they equivalent to those of wasm? If yes, how (technicalky) you achieve the reported speedup in verifying the security?

The lucet compiler and runtime each assume the other is implemented correctly, and its the job of some external system to make sure the runtime only loads code that came from the compiler. (We have infrastructure at Fastly that already does this for our edge cloud, and every use case will have different requirements).

The shared object code, when executed with lucet-runtime, should provide guarantees equivalent to those given by the wasm spec. However, we're not 100% to spec compliance yet, so there are some corners (e.g. import globals) that are not implemented. These dont cause a problem in practice, at the moment, because none of the toolchains we use to emit wasm use those features.

Loading code into the runtime is fast because its mostly a call to `dlopen`, followed by deserializing some metadata (with effort made to make this as efficient as possible). Instantiating modules is fast because it amortizes the syscall overhead by having pools of instances mostly-set-up ahead of time.

> Loading code into the runtime is fast because its mostly a call to `dlopen

Does that mean that you measure only loading and not the compilation and verification in your “50 ms” time?

Instantiation takes under 50 microseconds (us) on the lab machine I tested on, and 65us on my colleague's laptop. Loading the code takes about that long as well (see thread: https://twitter.com/acfoltzer/status/1111387279434485760). Compilation is not counted towards any of those tallies.

In our use case, we do compilation on a control plane system and distribute the shared object file to the fleet, so we aren't too concerned by it. For applications where compilation time is a bigger concern, I'm super impressed by this (still early) work on a one-pass wasm compiler: https://github.com/CraneStation/lightbeam

> 50 microseconds

Yes, sorry for my error in writing, of course, 50 ms would be only 20 times per second. Thanks a lot for your explanations.

so do we keep a pool of VMs with the so file loaded already and instantiate only the module on demand which means allocation of memory and setup of other data structures

Why did you write your own implementation rather than contribute directly to any of the projects with similar aims, e.g. wasmer or wasmtime.

We started the codebase that became Lucet in July 2017. It went through a few fast iterations, and by Jan 2018 we had Cranelift running with AOT compilation. In the early days of Cranelift that meant adding support for position-independent code output and filling in a bunch of gaps in the x86_64 encodings and other really low level stuff. At the time, wasmtime (under the name wasm-standalone, i think?) was a lot less mature, and wasmer was not public yet. So, in a sense, we did (& continue to) contribute to both of those runtimes via Cranelift and other dependencies like Faerie.

We spent the bulk of 2018 solving performance and integration problems, rather than cleaning up the codebase to the point where we could open source it. In the meantime wasmer was released, and both wasmtime and wasmer made a ton of progress. Now that our stuff is open source, it is easier for us to collaborate with other runtimes, possibly by moving more code back into the common Cranelift parent, or by adopting modules from each other.

Thanks for the answer, that makes a lot of sense.

I'm guessing Lucet was developed concurrently with the others, but unlike them, it had an extended period of internal development and testing first.

What would you say are the current main limitations of this approach? What is Lucet not meant to be good at?

At the moment, a lot of WASM tooling assumes instances interact with a JS engine. So, we aren't compatible with a bunch of existing tooling, like Rust's wasm-bindgen. We're working on our own tool to fill that hole in the ecosystem.

We also aren't 100% of the way to spec compliance yet. We have a plan to get there, but spent the last year or so putting the bulk of our effort into performance and integration with our edge cloud systems.

That's awesome. One of my main complaints with wasm-bindgen is it doesn't let you pull in any C libraries(vs older emscripten path) effectively walling off one of Rusts awesome capabilities(interop with a large established ecosystem).

Whatever tool that takes it's place here would be awesome if you plug in cleanly with the CC crate. I've had a lot of success using Rust as the glue between a lot of existing C/C++ libraries and would love to carry that forward to the WASM world.

I didn't know about WASI before and it looks great. As a C/C++ dev, one of my concerns about WASM was that most of native WASM runtimes are interfacing towards Emscripten which is not quite standardized.

Do you expect WASI will soon replace the current Emscripten exports interfaces?

We hope so! Mozilla has been working on WASI support from Rust, and our team is working on supporting it from AssemblyScript as well: https://github.com/jedisct1/wasa.