81–90 of 99 posts
Author here- happy to take questions.
Why did you write your own implementation rather than contribute directly to any of the projects with similar aims, e.g. wasmer or wasmtime.
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?
Earlier quoted context omitted.
But this is true of an ordinary Unix process too, via virtual memory. A Unix process can’t corrupt the kernel or other processes. But in practice there’s still a lot you can do with a buffer overflow vulnerability.
The issue with Unix process is that a process has the same rights than the user who ran that process. The design goal of WASI is to provide a capability-based system[1], so an attacker exploiting a buffer overflow wouldn't be able to access things that the original program wasn't supposed to. [1]: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...
Earlier quoted context omitted.
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 pro…
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...
Author here- happy to take questions.
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 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.
Author here- happy to take questions.
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 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.
Earlier quoted context omitted.
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 th…
Does that mean that you measure only loading and not the compilation and verification in your “50 ms” time?
Earlier quoted context omitted.
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 th…
> 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?
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
Earlier quoted context omitted.
Yes, bugs can always exist.
Not when you use a VM that actually cares about security at all layers, but anyway WASM is doing everything better. /s
Earlier quoted context omitted.
Not when you use a VM that actually cares about security at all layers, but anyway WASM is doing everything better. /s
Using such a VM requires rewriting existing C code. Wasm's approach allows that to happen incrementally, where it matters, by using memory safe languages like Rust, instead of relying on the VM.
So leaving memory tagging out of WASM was a deliberate design decision.
There are already better alternatives to write secure code if using C is not a requirement, so again nothing new on WASM other than its hype.