4 ms·

https://blog.cloudflare.com/announcing-wasi-on-workers/ https://blog.cloudflare.com/announcing-wasi-on-workers/ will probably open it up a bit for you with a co

by oxff 4y ago

https://blog.cloudflare.com/announcing-wasi-on-workers/ https://blog.cloudflare.com/announcing-wasi-on-workers/ will probably open it up a bit for you with a concrete example

baq 4y ago
Thanks for that. > Back to the future > For those of you who have been around for the better part of the past couple of decades, you may notice this looks very similar to RFC3875, better known as CGI (The Common Gateway Interface). While our example here certainly does not conform to the specification, you can imagine how this can be extended to turn the stdin of a basic 'command line' application into a full-blown http handler. they should've started with that ;)
btown 4y ago
I would add that it can be useful to have isolated runtimes even if you're not a PaaS. Say you need to parse an obscure file format that can be uploaded from untrusted users (and nowadays, that's all users). You've got some ancient C or C++ source code for the parser, but it hasn't been vetted for security or denial-of-service issues. Compile it to WASM, run it in an isolated runtime, and you can be confident that it won't be able to escape its sandbox while also minimizing startup times and using significantly fewer resources than needing a container for each invocation.
- jon-wood 4y ago
  Personally I’d want to be very cautious about this. It’s probably more secure than just running this untrusted binary directly on a server full of user uploaded content but I don’t know what level of confidence is should have in wasmtime not having any container escapes possible.
  - schemescape 4y ago
    Yes. Consider that Spectre allowed reading browser memory that wasn’t exposed to JavaScript from within the JS sandbox. Something similar probably would have been possible with WASM, if Spectre hadn’t already been found and mitigated. I love capability based limits like this (and in Deno), but they’re not a panacea.
- cesarb 4y ago
  > You've got some ancient C or C++ source code for the parser, but it hasn't been vetted for security or denial-of-service issues. Compile it to WASM, run it in an isolated runtime, and you can be confident that it won't be able to escape its sandbox This is not just a theory: according to https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again... Firefox does exactly that trick with five of its C or C++ dependencies.

by oxff 4y ago

https://blog.cloudflare.com/announcing-wasi-on-workers/ https://blog.cloudflare.com/announcing-wasi-on-workers/ will probably open it up a bit for you with a concrete example

baq 4y ago

Thanks for that. > Back to the future > For those of you who have been around for the better part of the past couple of decades, you may notice this looks very similar to RFC3875, better known as CGI (The Common Gateway Interface). While our example here certainly does not conform to the specification, you can imagine how this can be extended to turn the stdin of a basic 'command line' application into a full-blown http handler. they should've started with that ;)

btown 4y ago

I would add that it can be useful to have isolated runtimes even if you're not a PaaS. Say you need to parse an obscure file format that can be uploaded from untrusted users (and nowadays, that's all users). You've got some ancient C or C++ source code for the parser, but it hasn't been vetted for security or denial-of-service issues. Compile it to WASM, run it in an isolated runtime, and you can be confident that it won't be able to escape its sandbox while also minimizing startup times and using significantly fewer resources than needing a container for each invocation.

jon-wood 4y ago
Personally I’d want to be very cautious about this. It’s probably more secure than just running this untrusted binary directly on a server full of user uploaded content but I don’t know what level of confidence is should have in wasmtime not having any container escapes possible.
- schemescape 4y ago
  Yes. Consider that Spectre allowed reading browser memory that wasn’t exposed to JavaScript from within the JS sandbox. Something similar probably would have been possible with WASM, if Spectre hadn’t already been found and mitigated. I love capability based limits like this (and in Deno), but they’re not a panacea.
cesarb 4y ago
> You've got some ancient C or C++ source code for the parser, but it hasn't been vetted for security or denial-of-service issues. Compile it to WASM, run it in an isolated runtime, and you can be confident that it won't be able to escape its sandbox This is not just a theory: according to https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again... Firefox does exactly that trick with five of its C or C++ dependencies.