3 ms·

I wonder how safe the their (wazero's) approach is from the security point of view. According to the article (and I know it myself too after studying the Go run

by kgeist 2y ago

I wonder how safe the their (wazero's) approach is from the security point of view. According to the article (and I know it myself too after studying the Go runtime), the Go runtime is quite finicky when it comes to execution of foreign code because it can easily interfer with the goroutine scheduler, GC, etc. (unless you use CGO which deals with it, but they don't use it). As the article explains, it's easy to introduce random crashes by, say, innocently using a "wrong" register. Also, the Go runtime can change considerably from version to version (say, when they introduced preempted scheduling based on signals, or when they moved away from segmented stacks etc.), and so today Wazero may work OK but with a new Go version it may unexpectedly crash or corrupt memory in some subtle ways. Considering that the whole point of WASM is sandboxing, reading this article didn't make me feel very confident about the project.

ncruces 2y ago
If it gives you some confidence, wazero (the Go Wasm runtime) is used by the Go team (in CI) to test their own Go-to-Wasm compiler. So if they break wazero, they'll know pretty soon from failing tests of their own Wasm/WASI toolchain. https://go.dev/blog/wasi https://go.dev/blog/wasi https://github.com/golang/go/blob/go1.22.3/misc/wasm/go_wasip1_wasm_exec https://github.com/golang/go/blob/go1.22.3/misc/wasm/go_wasi... As for sandboxing, wazero tends to take sandboxing rather more seriously than other similar runtimes. Memory sandboxing is implemented through explicit bounds checks (rather than memory mapping and guard pages), which allows denser deployments and requires less runtime support. And, by default, the WASI implementation doesn't expose any capabilities (not even access to the system clock). You can also interject any relevant WASI host calls, and do your own filtering. And if the compiler is not your cup of tea, you can also use the (much slower) interpreter.
- kgeist 2y ago
  That's good to hear that the Go team themselves test wazero. Thank you for clarifying.

by kgeist 2y ago

ncruces 2y ago

If it gives you some confidence, wazero (the Go Wasm runtime) is used by the Go team (in CI) to test their own Go-to-Wasm compiler. So if they break wazero, they'll know pretty soon from failing tests of their own Wasm/WASI toolchain. https://go.dev/blog/wasi https://go.dev/blog/wasi https://github.com/golang/go/blob/go1.22.3/misc/wasm/go_wasip1_wasm_exec https://github.com/golang/go/blob/go1.22.3/misc/wasm/go_wasi... As for sandboxing, wazero tends to take sandboxing rather more seriously than other similar runtimes. Memory sandboxing is implemented through explicit bounds checks (rather than memory mapping and guard pages), which allows denser deployments and requires less runtime support. And, by default, the WASI implementation doesn't expose any capabilities (not even access to the system clock). You can also interject any relevant WASI host calls, and do your own filtering. And if the compiler is not your cup of tea, you can also use the (much slower) interpreter.

kgeist 2y ago
That's good to hear that the Go team themselves test wazero. Thank you for clarifying.