4 ms·

And all of those basic instructions only operate in a protected memory space. There is no stack to manipulate,no way to do syscalls or interact with the host e

And all of those basic instructions only operate in a protected memory space. There is no stack to manipulate,no way to do syscalls or interact with the host environment in any way that is not mediated by the runtime. Wasm instructions are not native instructions. The spec [1] clearly states that Webassembly is sandboxed. A non-sandboxing implementation would be either non-compliant or have bugs (which admittedly they most likely do at this point, considering they are still new). [1] https://webassembly.github.io/spec/core/intro/introduction.html#security-considerations https://webassembly.github.io/spec/core/intro/introduction.h...

devwastaken 7y ago
Which is all completely dependent upon the implimentation of the executing software. Lets take it from the beginning, 1. wasm is a set of instructions. 2. those instructions have to be turned into instructions the hardware understands to execute them. No where in here is there a requirement of sandboxing. With a sandbox, a 'protected memory space' is dependent upon the implimentor. There's no such thing as a magic software sandbox that you just drop into software and congrats, secure. You impliment it.
- the_duke 7y ago
  > No where in here is there a requirement of sandboxing Let me quote the Webassembly spec [1]: > WebAssembly provides no ambient access to the computing environment in which code is executed. Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking functions provided by the embedder and imported into a WebAssembly module. [1] https://webassembly.github.io/spec/core/intro/introduction.html#security-considerations https://webassembly.github.io/spec/core/intro/introduction.h...
  - devwastaken 7y ago
    There is a seperation between spec and implimentation. That quote doesn't at all disagree with me. That's how wasm is meant to be, but doesn't give any detail as to how that's achieved programatically. You can impliment all of that and still have a vulnerable runtime because of how you implimented it. You can also just put in system access as functions, as some runtimes do because they don't care about sandboxing.
    - thayne 7y ago
      > That's how wasm is meant to be, but doesn't give any detail as to how that's achieved programatically True, but a conforming implementation has at least some sandboxing, since it prevents arbitrary memory access. But the degree to which it is sandboxed depends on the functions that are exposed by the runtime.
    - Dylan16807 7y ago
      > You can impliment all of that and still have a vulnerable runtime because of how you implimented it. This applies to every single sandboxed language in the world. The instructions are designed so that sandboxing the actual core is trivial, and the spec says that you have to sandbox outside of deliberate pass-throughs. That's about the best you can possibly do. If languages can qualify as sandboxed, it sounds like WASM qualifies. (And if they can't, then we're using a broken definition of "sandboxed".)
      - devwastaken 7y ago
        Languages cannot qualify as sandboxed unless that language comes with a runtime that has a sandbox. Wasm does not. There is no such thing as 'trivial to sandbox'. Wasm doesn't introduce anything new in terms of it's instructions, it's bound by all the same mistakes and errors developers will make in sandboxing as there has been in the past.
        Dylan16807 7y ago
        So even if all possible runtimes have to be sandboxed or they're not actually implementing the language, it's not possible for a language to qualify as "sandboxed"? Then I stand by what I said before. Your definition is broken, and you're making a semantic argument rather than actually discussing eBPF and WASM. When you see someone say "sandboxed language" read it as "language where conforming implementations are by definition sandboxed". WASM meets that definition, as far as I can tell. When you see someone say "WASM is sandboxed" read it as "any runtime that implements the WASM spec is sandboxed".
  - wahern 7y ago
    Those limitations are true of most virtual machines. Lua bytecode has no opcodes for doing I/O, invoking syscalls, or anything else that interacts outside the VM environment. AFAICT, Python is similar with the exception of some opcodes for printing to stdout. To interact with the outside environment you must load and invoke code from modules, so access is intrinsically limited by whatever modules are permitted to be loaded. In Lua a new VM state context has no modules loaded at all--not even for the string module; nor any ability to load modules--the C application needs to explicitly load the package module to register "require" in the environment.
- simias 7y ago
  I don't see where you're going with that. Doesn't that definition apply to eBPF as well? I feel like you're trying to win a purely semantic argument which doesn't really advance the discussion.

devwastaken 7y ago

Which is all completely dependent upon the implimentation of the executing software. Lets take it from the beginning, 1. wasm is a set of instructions. 2. those instructions have to be turned into instructions the hardware understands to execute them. No where in here is there a requirement of sandboxing. With a sandbox, a 'protected memory space' is dependent upon the implimentor. There's no such thing as a magic software sandbox that you just drop into software and congrats, secure. You impliment it.

the_duke 7y ago
> No where in here is there a requirement of sandboxing Let me quote the Webassembly spec [1]: > WebAssembly provides no ambient access to the computing environment in which code is executed. Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking functions provided by the embedder and imported into a WebAssembly module. [1] https://webassembly.github.io/spec/core/intro/introduction.html#security-considerations https://webassembly.github.io/spec/core/intro/introduction.h...
- devwastaken 7y ago
  There is a seperation between spec and implimentation. That quote doesn't at all disagree with me. That's how wasm is meant to be, but doesn't give any detail as to how that's achieved programatically. You can impliment all of that and still have a vulnerable runtime because of how you implimented it. You can also just put in system access as functions, as some runtimes do because they don't care about sandboxing.
  - thayne 7y ago
    > That's how wasm is meant to be, but doesn't give any detail as to how that's achieved programatically True, but a conforming implementation has at least some sandboxing, since it prevents arbitrary memory access. But the degree to which it is sandboxed depends on the functions that are exposed by the runtime.
  - Dylan16807 7y ago
    > You can impliment all of that and still have a vulnerable runtime because of how you implimented it. This applies to every single sandboxed language in the world. The instructions are designed so that sandboxing the actual core is trivial, and the spec says that you have to sandbox outside of deliberate pass-throughs. That's about the best you can possibly do. If languages can qualify as sandboxed, it sounds like WASM qualifies. (And if they can't, then we're using a broken definition of "sandboxed".)
    - devwastaken 7y ago
      Languages cannot qualify as sandboxed unless that language comes with a runtime that has a sandbox. Wasm does not. There is no such thing as 'trivial to sandbox'. Wasm doesn't introduce anything new in terms of it's instructions, it's bound by all the same mistakes and errors developers will make in sandboxing as there has been in the past.
      - Dylan16807 7y ago
        So even if all possible runtimes have to be sandboxed or they're not actually implementing the language, it's not possible for a language to qualify as "sandboxed"? Then I stand by what I said before. Your definition is broken, and you're making a semantic argument rather than actually discussing eBPF and WASM. When you see someone say "sandboxed language" read it as "language where conforming implementations are by definition sandboxed". WASM meets that definition, as far as I can tell. When you see someone say "WASM is sandboxed" read it as "any runtime that implements the WASM spec is sandboxed".
- wahern 7y ago
  Those limitations are true of most virtual machines. Lua bytecode has no opcodes for doing I/O, invoking syscalls, or anything else that interacts outside the VM environment. AFAICT, Python is similar with the exception of some opcodes for printing to stdout. To interact with the outside environment you must load and invoke code from modules, so access is intrinsically limited by whatever modules are permitted to be loaded. In Lua a new VM state context has no modules loaded at all--not even for the string module; nor any ability to load modules--the C application needs to explicitly load the package module to register "require" in the environment.
simias 7y ago
I don't see where you're going with that. Doesn't that definition apply to eBPF as well? I feel like you're trying to win a purely semantic argument which doesn't really advance the discussion.