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?
Lucet: Native WebAssembly Compiler and Runtime
11–20 of 99 posts
Re: Lucet: Native WebAssembly Compiler and Runtime
#12how 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?
We're not quite there yet, but we're working on answering those questions right now. Stay tuned!
Re: Lucet: Native WebAssembly Compiler and Runtime
#13> 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.?
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... For speculative execution, we don't yet implement all of the mitigations possible in Lucet, but will in the near future.
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.
Re: Lucet: Native WebAssembly Compiler and Runtime
#14Why use this as opposed to Google NaCl or PNaCl?
(P)NaCl is dead: https://www.theregister.co.uk/2017/05/31/googles_portable_na...
Re: Lucet: Native WebAssembly Compiler and Runtime
#15Why use this as opposed to Google NaCl or PNaCl?
The NaCl/PNaCl team is working on Web Assembly these days, for one.
Re: Lucet: Native WebAssembly Compiler and Runtime
#16Why use this as opposed to Google NaCl or PNaCl?
Google already deprecated them in favor of WebAssembly.
Re: Lucet: Native WebAssembly Compiler and Runtime
#17Author here- happy to take questions.
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.
Re: Lucet: Native WebAssembly Compiler and Runtime
#18Interesting! I wonder this compares with other WebAssembly runtimes (Wasmer?)
Re: Lucet: Native WebAssembly Compiler and Runtime
#19Why use this as opposed to Google NaCl or PNaCl?
(P)NaCl is dead a long long time ago
Re: Lucet: Native WebAssembly Compiler and Runtime
#20Earlier quoted context omitted.
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... For speculative execution, we don't yet implement all of the mitigations possible in Lucet, but will in the near future.
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.
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...