7 ms·

Wonder if you could build something similar using Go, A goroutine's overhead is only about 2KB. No idea how easy it would be to sandbox it.

wmf 8y ago
It wouldn't be easy at all to sandbox it; that's the problem with every language that isn't Java or JS. (And I think people gave up on Java sandboxing a decade or more ago.)
- madmax96 8y ago
  What about JavaScript makes sandboxing easier than, say, Go, Python, etc?
  - wmf 8y ago
    Just the fact that it was designed for sandboxing hostile code from the beginning.
    - madmax96 8y ago
      How does that design actually manifest itself? I don't know very much about this - what technical details about JavaScript make this easier? And then why doesn't Node support this kind of sandboxing, but V8 does, if it's so much easier to support sandboxing than other languages?
      - elithrar 8y ago
        Take a look here, at the V8 embedding docs: https://v8.dev/docs/embed https://v8.dev/docs/embed It specifically covers isolates vs. contexts, which should help contextualize it.
      - jerf 8y ago
        The primary advantage is that it's already done, really. It's not hard to define isolated environments in almost any language you could name ("I should be able to have two runtime environments that support as much of the original language as possible, and they should not be able to affect each other" - a thousand i's to dot and t's to cross, but that pretty much captures the idea), but implementing them is another thing entirely. So much of the rest of language design tends to cut the other way, making sure that things are hooked together deeply for the convenience of the programmer. I'm not particularly convinced Javascript is that much better than any other language as the language goes, but the implementation is far ahead of almost anything else. I know of other implementations of this idea in other languages ("Safe" in Perl [1], various attempts at sandboxing in Python which have generally failed, Safe Haskell [2], many others), but without the browser use case driving them forward, they tend to be poorly tested and even decay over time. It tends to be a use case popular enough to get some stab at support, but not popular enough to quite result in a robust, real-world-tested library support. The browser is an exceptional use case. [1]: https://perldoc.perl.org/Safe.html https://perldoc.perl.org/Safe.html [2]: https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell
  - deleted 8y ago
    [deleted]
  - weberc2 8y ago
    There's not much that makes sandboxing _easier_ for JS, it's just that the economics favor JavaScript (because it's a useful feature for browsers and browsers are installed on billions of devices).
- PyroLagus 8y ago
  > that's the problem with every language that isn't Java or JS. Or WebAssembly, for which many languages now have a backend.
- parhamn 8y ago
  WASM will probably make sandboxing across languages a lot easier. I wonder what would happen if you ran a golang wasm binary on a the golang wagon WASM interpereter [1] [1] https://github.com/go-interpreter/wagon https://github.com/go-interpreter/wagon
  - kodablah 8y ago
    > I wonder what would happen if you ran a golang wasm binary on a the golang wagon WASM interpereter IIRC it won't quite work because the plumbing required for WASM on the host side isn't done there yet [0]. The plumbing is mostly [1]. In a project I did on the side to reduce Go WASM size and startup time [2], I built just enough of this plumbing to solve my needs. Go initially targets only JS [3], so sadly us with non-web use cases might have to wait. 0 - https://github.com/go-interpreter/wagon/issues/69 https://github.com/go-interpreter/wagon/issues/69 1 - https://github.com/golang/go/blob/master/misc/wasm/wasm_exec.js https://github.com/golang/go/blob/master/misc/wasm/wasm_exec... 2 - https://github.com/cretz/go-wasm-bake https://github.com/cretz/go-wasm-bake 3 - https://github.com/neelance/go/pull/7#issuecomment-377298992 https://github.com/neelance/go/pull/7#issuecomment-377298992
    - parhamn 8y ago
      Neat, thanks!
CodeWriter23 8y ago
> Wonder if you could build something similar using Go, FTA “In an Isolate universe you have to either write your code in Javascript (we use a lot of TypeScript), or a language which targets WebAssembly like Go or Rust.”
- smadge 8y ago
  They were talking about reimplementing isolates and a similar multi tenant cloud computing environment in go.
  - zackbloom 8y ago
    No, the previous commenter was correct. You can run any WASM targeting language on Workers.
    - smadge 8y ago
      I agree that from this article it seems possible to run go on cloudflare workers by targeting WASM, it’s still worthwhile to consider what a native go implementation would look like.
foobiekr 8y ago
A native client could do.
shoo 8y ago
i dont know very much about go, or sandboxing, but for starters, you might need to do something like: disable syscalls, disable ability to do operations that could hog resources, such as spawning more goroutines

wmf 8y ago

It wouldn't be easy at all to sandbox it; that's the problem with every language that isn't Java or JS. (And I think people gave up on Java sandboxing a decade or more ago.)

madmax96 8y ago
What about JavaScript makes sandboxing easier than, say, Go, Python, etc?
- wmf 8y ago
  Just the fact that it was designed for sandboxing hostile code from the beginning.
  - madmax96 8y ago
    How does that design actually manifest itself? I don't know very much about this - what technical details about JavaScript make this easier? And then why doesn't Node support this kind of sandboxing, but V8 does, if it's so much easier to support sandboxing than other languages?
    - elithrar 8y ago
      Take a look here, at the V8 embedding docs: https://v8.dev/docs/embed https://v8.dev/docs/embed It specifically covers isolates vs. contexts, which should help contextualize it.
    - jerf 8y ago
      The primary advantage is that it's already done, really. It's not hard to define isolated environments in almost any language you could name ("I should be able to have two runtime environments that support as much of the original language as possible, and they should not be able to affect each other" - a thousand i's to dot and t's to cross, but that pretty much captures the idea), but implementing them is another thing entirely. So much of the rest of language design tends to cut the other way, making sure that things are hooked together deeply for the convenience of the programmer. I'm not particularly convinced Javascript is that much better than any other language as the language goes, but the implementation is far ahead of almost anything else. I know of other implementations of this idea in other languages ("Safe" in Perl [1], various attempts at sandboxing in Python which have generally failed, Safe Haskell [2], many others), but without the browser use case driving them forward, they tend to be poorly tested and even decay over time. It tends to be a use case popular enough to get some stab at support, but not popular enough to quite result in a robust, real-world-tested library support. The browser is an exceptional use case. [1]: https://perldoc.perl.org/Safe.html https://perldoc.perl.org/Safe.html [2]: https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell
- deleted 8y ago
  [deleted]
- weberc2 8y ago
  There's not much that makes sandboxing _easier_ for JS, it's just that the economics favor JavaScript (because it's a useful feature for browsers and browsers are installed on billions of devices).
PyroLagus 8y ago
> that's the problem with every language that isn't Java or JS. Or WebAssembly, for which many languages now have a backend.
parhamn 8y ago
WASM will probably make sandboxing across languages a lot easier. I wonder what would happen if you ran a golang wasm binary on a the golang wagon WASM interpereter [1] [1] https://github.com/go-interpreter/wagon https://github.com/go-interpreter/wagon
- kodablah 8y ago
  > I wonder what would happen if you ran a golang wasm binary on a the golang wagon WASM interpereter IIRC it won't quite work because the plumbing required for WASM on the host side isn't done there yet [0]. The plumbing is mostly [1]. In a project I did on the side to reduce Go WASM size and startup time [2], I built just enough of this plumbing to solve my needs. Go initially targets only JS [3], so sadly us with non-web use cases might have to wait. 0 - https://github.com/go-interpreter/wagon/issues/69 https://github.com/go-interpreter/wagon/issues/69 1 - https://github.com/golang/go/blob/master/misc/wasm/wasm_exec.js https://github.com/golang/go/blob/master/misc/wasm/wasm_exec... 2 - https://github.com/cretz/go-wasm-bake https://github.com/cretz/go-wasm-bake 3 - https://github.com/neelance/go/pull/7#issuecomment-377298992 https://github.com/neelance/go/pull/7#issuecomment-377298992
  - parhamn 8y ago
    Neat, thanks!

CodeWriter23 8y ago

> Wonder if you could build something similar using Go, FTA “In an Isolate universe you have to either write your code in Javascript (we use a lot of TypeScript), or a language which targets WebAssembly like Go or Rust.”

smadge 8y ago
They were talking about reimplementing isolates and a similar multi tenant cloud computing environment in go.
- zackbloom 8y ago
  No, the previous commenter was correct. You can run any WASM targeting language on Workers.
  - smadge 8y ago
    I agree that from this article it seems possible to run go on cloudflare workers by targeting WASM, it’s still worthwhile to consider what a native go implementation would look like.

foobiekr 8y ago

A native client could do.

shoo 8y ago

i dont know very much about go, or sandboxing, but for starters, you might need to do something like: disable syscalls, disable ability to do operations that could hog resources, such as spawning more goroutines