23 ms·

Lua allows full control over which APIs you want to expose to a script you embed in your application. With some effort you can even expose only a constrained ve

by brabel 3y ago

Lua allows full control over which APIs you want to expose to a script you embed in your application. With some effort you can even expose only a constrained version of the `os` module for example which only lets you access a few resources. Why do you believe WASM can do better here? In fact, as far as I know , there's nothing in WASM that lets you sandbox it yet once you've given it WASI access (unless you're talking about host specific features, which are NOT part of WASM spec itself).

josephg 3y ago
Yeah lua is a weird example because it’s actually amazing at this. Lua gives you a massive amount of control over what scripts can access. It is much safer than pulling in an opaque C library that works via ffi. Eg a nodejs native module. Those are written in C and can indeed sell your data to North Korea. (Just like any other package in npm.) I’m excited by the idea of being able to depend on 3rd party code without it having access to my entire OS.
ncruces 3y ago
That depends entirely on the runtime, and its WASI implementation. wazero [1], which I'm most familiar with, allows you to decide in a relatively fine-grained way what capabilities your WASI module will have: command line arguments, environment variables, stdin/out/err, monotonic/wall clock, sleeping, even yielding CPU… Maybe more importantly, filesystem access can be fully emulated, or sandboxed to a specific folder, or have some directories mounted read-only, etc; it's very much up to you. I've used it to wrap command line utilities, and package them as Go libraries. For one example, dcraw [2]. WASM makes this memory safe, and I can sandbox it to access only the single file I want it to process (which can be a memory buffer, or something in blob storage, if I want it to). Notice in [3] how you provide an io.ReadSeeker which could be anything from a file, a buffer in memory, or an HTTP resource. The spaghetti C that dcraw is made of won't be able to access any other file, bring your server down, etc. 1: https://wazero.io/ https://wazero.io/ 2: https://dechifro.org/dcraw/ https://dechifro.org/dcraw/ 3: https://pkg.go.dev/github.com/ncruces/rethinkraw/pkg/dcraw https://pkg.go.dev/github.com/ncruces/rethinkraw/pkg/dcraw
- emmanueloga_ 3y ago
  Wazero looks super cool. I saw somewhere that programs can be run with a timeout, which sounds great for sandboxing. The program input is just a slice of bytes [1], so an interesting use case would be to use something like Nats [2] to distribute programs to different servers. Super simple distributed computing! -- 1: https://github.com/tetratelabs/wazero/blob/main/examples/basic/add.go#L45C38-L45C38 https://github.com/tetratelabs/wazero/blob/main/examples/bas... 2: https://natsbyexample.com/examples/messaging/pub-sub/go https://natsbyexample.com/examples/messaging/pub-sub/go
  - ncruces 3y ago
    Yes: if so configured, wazero respects context cancelation (including, but not limited to, timeouts). This has a slight toll on performance: a call back from WASM AOT-compiled-assembly into Go is introduced regularly (on every backwards jump?) to give the Go runtime the opportunity to yield the goroutine and update the context (and break infinite loops), even when GOMAXPROCS=1. Coordinating with the Go scheduler might be an area where there's some room for improvement, if fact.

by brabel 3y ago

josephg 3y ago

Yeah lua is a weird example because it’s actually amazing at this. Lua gives you a massive amount of control over what scripts can access. It is much safer than pulling in an opaque C library that works via ffi. Eg a nodejs native module. Those are written in C and can indeed sell your data to North Korea. (Just like any other package in npm.) I’m excited by the idea of being able to depend on 3rd party code without it having access to my entire OS.

ncruces 3y ago

That depends entirely on the runtime, and its WASI implementation. wazero [1], which I'm most familiar with, allows you to decide in a relatively fine-grained way what capabilities your WASI module will have: command line arguments, environment variables, stdin/out/err, monotonic/wall clock, sleeping, even yielding CPU… Maybe more importantly, filesystem access can be fully emulated, or sandboxed to a specific folder, or have some directories mounted read-only, etc; it's very much up to you. I've used it to wrap command line utilities, and package them as Go libraries. For one example, dcraw [2]. WASM makes this memory safe, and I can sandbox it to access only the single file I want it to process (which can be a memory buffer, or something in blob storage, if I want it to). Notice in [3] how you provide an io.ReadSeeker which could be anything from a file, a buffer in memory, or an HTTP resource. The spaghetti C that dcraw is made of won't be able to access any other file, bring your server down, etc. 1: https://wazero.io/ https://wazero.io/ 2: https://dechifro.org/dcraw/ https://dechifro.org/dcraw/ 3: https://pkg.go.dev/github.com/ncruces/rethinkraw/pkg/dcraw https://pkg.go.dev/github.com/ncruces/rethinkraw/pkg/dcraw

emmanueloga_ 3y ago
Wazero looks super cool. I saw somewhere that programs can be run with a timeout, which sounds great for sandboxing. The program input is just a slice of bytes [1], so an interesting use case would be to use something like Nats [2] to distribute programs to different servers. Super simple distributed computing! -- 1: https://github.com/tetratelabs/wazero/blob/main/examples/basic/add.go#L45C38-L45C38 https://github.com/tetratelabs/wazero/blob/main/examples/bas... 2: https://natsbyexample.com/examples/messaging/pub-sub/go https://natsbyexample.com/examples/messaging/pub-sub/go
- ncruces 3y ago
  Yes: if so configured, wazero respects context cancelation (including, but not limited to, timeouts). This has a slight toll on performance: a call back from WASM AOT-compiled-assembly into Go is introduced regularly (on every backwards jump?) to give the Go runtime the opportunity to yield the goroutine and update the context (and break infinite loops), even when GOMAXPROCS=1. Coordinating with the Go scheduler might be an area where there's some room for improvement, if fact.