
Lucet: Native WebAssembly Compiler and Runtime - kickdaddy
https://www.fastly.com/blog/announcing-lucet-fastly-native-webassembly-compiler-runtime
======
steveklabnik
The wasm runtime wars are heating up! Exciting times :)

Really pumped to see this open sourced. And the performance properties look
awesome.

One interesting thing we’re seeing in this space is sort of two parallel paths
emerge: do you want to support JavaScript, or not? An example of the former is
CloudFlare and their Workers platform. Hopefully they’ll follow Fastly’s lead
and open source their runtime too, but it’s built on top of V8 because they
want to support JavaScript. You also gain the additional advantage of all the
engineering that Google puts into V8.

The other option is stuff like Lucent, wasmer, and wasmtime. By dropping the
JavaScript requirement, you can build something that really screams, as seen
here. You can partially regain _some_ support via AssemblyScript, the
TypeScript subset that compiles to JS. But we haven’t seen JavaScript compile
directly to wasm yet because if you want that, well, V8 exists. And you do
have to build it all yourself.

JavaScript is one of most popular programming programming languages that
exists. Time will tell which approach is better, but it’s really fun to watch
all of this cool technology explode onto the scene right now.

(Disclaimer: I have connections to all of these projects in various ways.
Everyone involved in all of them is doing great work.)

~~~
k__
Sounds really exciting.

Are comparisons to things like the JVM or native binaries already possible?

~~~
steveklabnik
I'm not 100% sure what you mean by that final sentence, could you maybe
elaborate?

~~~
k__
Sure.

Does WASM have better performance than the JVM? If not, could it have better
performance theoretically? Is it more secure? How much slower than a regular
binary would it be? etc.

~~~
steveklabnik
Ah, cool.

Performance is really difficult to properly measure, because each of these
projects have different performance profiles, and new ones keep popping up,
like Lucet did today! And if you write a benchmark, then something like
[https://hacks.mozilla.org/2018/10/calls-between-
javascript-a...](https://hacks.mozilla.org/2018/10/calls-between-javascript-
and-webassembly-are-finally-fast-%F0%9F%8E%89/) happens, and all of a sudden
the numbers are all different. So it's really hard to speak about wasm
generally this way, it's better to talk about specific implementations and
use-cases, IMHO. And to understand that benchmarks need to be updated in order
to still be relevant.

Security is an interesting axis; like the JVM (as far as I know), wasm is
memory safe by design. But security is more holistic than that. One
interesting thing about wasm is that you have to say up-front what things you
want to call in the host, which provides the ability for the host to say
"nope, you're not gonna be able to do that." And of course, logic bugs can
lead to security vulnerabilities in all of these platforms.

~~~
ridiculous_fish
I think wasm's memory safety is weaker than JVM. wasm's checking occurs at
control flow points and the linear memory boundary, but does not extend down
to individual objects. For example arrays are not bound checked in wasm.

~~~
steveklabnik
Wasm doesn't really have "arrays", so I don't think wasm checking them would
really make sense. I guess you could argue that this is a distinction without
a difference. You still won't get memory unsafety, which in my mind, is the
higher order bit. YMMV of course.

~~~
ridiculous_fish
You _do_ get memory unsafety. OpenSSL compiled to wasm would still be
vulnerable to Heartbleed. The JVM would prevent it.

~~~
steveklabnik
Please re-read what Rusky said; the point is about the boundary. Yes, wasm
programs can mess up their own memory. That’s not what I’m talking about. I
should be more clear about this in the future though, thanks.

~~~
ridiculous_fish
I don't understand this point. We don't say that C is memory safe because of
the kernel boundary, even though this boundary does provide important safety
guarantees.

edit: I guess this viewpoint makes sense for the use case of "thousands of
wasm programs in the same process." They are protected from each other, in a
sense qualitatively the same as Unix processes. This is still a much weaker
guarantee than the JVM provides.

~~~
littlestymaar
The goal is to allow existing C code to run, so in the end you'll need the
same freedom when it comes to memory access. The difference between this and
plain process is that the sandbox uses a capability-based security model,
instead of giving all the user's rights to the process [1].

[1]: [https://hacks.mozilla.org/2019/03/standardizing-wasi-a-
webas...](https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-
system-interface/)

~~~
hawski
There is not a mention of memory safety in this post. It's very confusing term
in this context. I wouldn't call running a binary with syscall interception
(with qemu for example) as "memory safe".

------
phickey
Author here- happy to take questions.

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

~~~
phickey
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.

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

------
peter998
Interesting! I wonder this compares with other WebAssembly runtimes (Wasmer?)

~~~
syrusakbary
Thanks for asking! I'm Syrus, I started the Wasmer project.

Lucet just released, but so far these are the current differences as far as I
can tell:

1\. Wasmer is meant to execute any WebAssembly file and run on any platform.
Wasmer currently runs on Mac, Linux and Windows. Lucet only works on Linux at
the moment, since its main goal is to be executed on Fastly's infra.

2\. We support multiple compiler backends: dynasm, cranelift and LLVM. Each
with a tradeoff between runtime speed and compilation speed (more info here
[https://github.com/wasmerio/wasmer/tree/master/lib#backends](https://github.com/wasmerio/wasmer/tree/master/lib#backends)
). Lucet's architecture only supports one backend at the moment.

3\. Wasmer has multiple interfaces/ABI integrations, including Emscripten, and
soon WASI. Lucet initially shipped with WASI support, which is awesome.

4\. Wasmer has a C/C++ API and its runtime can be integrated with other
languages (C/C++, Rust and PHP at the moment)

And, of course... a link to the project if anyone else wants to take a look!
[https://github.com/wasmerio/wasmer](https://github.com/wasmerio/wasmer)

~~~
phickey
That is a good summary! Lucet's runtime has a C API as well. We haven't
created bindings to languages beyond C and Rust, but it should be pretty
straightforward using the C API.

~~~
syrusakbary
Thanks for the correction! And congrats for the great work

------
StavrosK
Now that I see this, a question comes to mind: Why do we have yet another VM?
Why didn't browsers just implement LLVM? Is it the sandbox?

Don't get me wrong, I'm excited to see wasm spread, but the question does
cross my mind.

~~~
steveklabnik
LLVM is not really a VM in the sense of the JVM. LLVM-IR is not platform
independent, and was never intended for this use-case.

It is also _significantly_ more complex than wasm, which is partially why wasm
ended up working. Start small, add over time: that's the way of the web
platform.

~~~
writepub
There's a subset of LLVM-IR that IS platform independent. PNacl, and many
others rely on this.

The reason for wasm's victory is two found:

1\. WASM is a stack based VM (LLVM IR is register based). Additionally,
instructions chosen for wasm were inspired by the byte code representation
used in existing JS JIT compilers. This meant that WASM almost fit
effortlessly into the browser compiler pipeline. Compare this to adding the
LLVM jit engine that the nacl philosophy uses. WASM was easier to implement.
Stack based VMs are also (apparently) easier to sandbox, with a significantly
lower attack surface

2\. Firefox was philosophically against nacl/PNacl. Considering how Webview
Safari eventually chose LLVM jit for it's JS JIT, as of 2019, PNacl would
probably have won, given Microsoft (chromium edge), Google and Safari all
support LLVM jit anyways.

~~~
kryptiskt
Safari ditched LLVM JIT for B3 a couple of years ago and V8 has never used it,
so it was never really established for JS engines.

------
azakai
> With Lucet, Fastly’s edge cloud can execute tens of thousands of WebAssembly
> programs simultaneously, _in the same process_ , without compromising
> security. [emphasis mine]

How does it handle Spectre, etc.?

~~~
phickey
We have a security document that addresses the big picture, and this specific
concern as well:
[https://github.com/fastly/lucet/blob/master/SECURITY.md#cave...](https://github.com/fastly/lucet/blob/master/SECURITY.md#caveats)
For speculative execution, we don't yet implement all of the mitigations
possible in Lucet, but will in the near future.

~~~
tick_tock_tick
So currently it does compromise on security? Seems extremely misleading to
claim any security if you are just currently ignoring the last years worth of
major security issues.

~~~
Yetanfou
From what I gather the thing is based on WASI which in early beta and for
which many parts don't exist or don't work, networking and file access being a
few of those [1]: _Note that everything here is a prototype, and while a lot
of stuff works, there are numerous missing features and some rough edges. One
big thing that 's not done yet is the actual mechanism to provide a directory
as a pre-opened capability, to allow files to be opened. Some of the pieces
are there (__wasilibc_register_preopened_fd) but they're not used yet.
Networking support is also incomplete._

In other words, this is a somewhat premature announcement when it comes to
fulfilling those promises.

[1]
[https://github.com/CraneStation/wasmtime/blob/master/docs/WA...](https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-
intro.md)

~~~
sunfish
That sentence about pre-opened directory capabilities not being supported is
actually outdated. They're supported now, so I've now updated the
documentation. Thanks for pointing that out!

------
alexellisuk
Excited to see this come about and how it could be used with the OpenFaaS
watchdog on Kubernetes.
[https://docs.openfaas.com/architecture/watchdog/](https://docs.openfaas.com/architecture/watchdog/)
\- is the 5 nano seconds the time to fork at the OS level or a kind of in-
process hot performance?

I got an error with the example however.. is everyone else seeing the same
thing?

Unpacking wasi-sdk (3.0) ... Setting up wasi-sdk (3.0) ... Removing
intermediate container d552f4538e26 \---> 713ff6032205 Step 8/8 : ENV
WASI_SDK=/opt/wasi-sdk \---> Running in 4189f307a30e Removing intermediate
container 4189f307a30e \---> a142a5620a28 Successfully built a142a5620a28
Successfully tagged lucet-dev:latest Lucet hasn't been installed yet...
installing... Creating a RELEASE build cargo build --all --release --bins
--lib error: failed to read `/lucet/pwasm-validation/Cargo.toml`

Caused by: No such file or directory (os error 2) Makefile:11: recipe for
target 'build' failed make: __* [build] Error 101

~~~
phickey
You need to checkout submodules - $ git submodule init && git submodule
update. Sorry, multiple people have reported this problem, and we're adding it
to the docs right now!

~~~
jedisct1
Indeed.

And even if you know that a project uses submodules, forgetting `--recursive`
happens constantly.

The script will now automatically install the required submodules.

------
vortico
Native WebAssembly sure is an exciting topic. But I can't think of a single
concrete use case that someone could use---besides having another standard for
secure bytecode to choose from. Help?

~~~
steveklabnik
As the blog post mentions,

> Lucet is designed to take WebAssembly beyond the browser, and build a
> platform for faster, safer execution on Fastly’s edge cloud.

> Lucet is the engine behind Terrarium, our experimental platform for edge
> computation using WebAssembly. Soon, we will make it available on Fastly’s
> edge cloud as well.

You can see the Terrarium announcement here:
[https://www.fastly.com/blog/edge-programming-rust-web-
assemb...](https://www.fastly.com/blog/edge-programming-rust-web-assembly)

So that's at one concrete use case for you! I'm sure we'll be seeing more pop
up in the future, there's so much going on here.

------
cagenut
how does it look like this will work from a stack and a request/response flow
perspective?

meaning, am I calling it as a function from within my vcl config? or am i
mapping my service-id straight to a binary?

~~~
phickey
We're not quite there yet, but we're working on answering those questions
right now. Stay tuned!

------
gaze
Why use this as opposed to Google NaCl or PNaCl?

~~~
jedisct1
(P)NaCl is dead:
[https://www.theregister.co.uk/2017/05/31/googles_portable_na...](https://www.theregister.co.uk/2017/05/31/googles_portable_native_client_to_be_killed/)

------
cck68
Can you comment on how big an effort it would be to support arm platforms?

------
sansnomme
How does Lucet's WebAssembly performance compare to LuaJIT (one of the fastest
JITs in existence) right now including VM warm-up time? Also, what's the GUI
story like outside of browsers?

~~~
MuffinFlavored
What other fast JITs in existence are there that are worth noting?

~~~
saagarjha
HotSpot, the JavaScript JITs?

