3 ms·

The cross-language interoperability of WebAssembly seems practically like a happy side-effect of its design; I don't think it would look much differently at pre

The cross-language interoperability of WebAssembly seems practically like a happy side-effect of its design; I don't think it would look much differently at present if it had originally been built to target only C (in a sandboxable way). Most of the article still applies even if you ignore other language support. The first priority for WebAssembly seems to be making things strongly sandboxed.

pjmlp 7y ago
Actually it fails to properly sandbox C derived languages versus what hardware memory tagging like SPARC ADI and ARM are capable of, because it doesn't do bounds checks inside linear memory blocks.
- AgentME 7y ago
  WebAssembly strongly sandboxes the module from affecting the world outside of it, not from affecting itself. Isn't that the usual use of the word sandbox? The sandbox imposes a boundary between the inside and outside, but it doesn't directly change how things work on the inside. It might be nice to have features for enforcing memory bounds within a module, but I wouldn't call those sandboxing, or call the lack of those features a deficit of the sandbox.
  - pjmlp 7y ago
    It is a security deficiency, hence why MSIL that contains certain C++ features is tainted as unsafe by the security verifier. Some other bytecodes like Unisys ClearPath mainframes follow the same approach when using unchecked bounds access. WebAssembly folks just hand wave it as not an issue.
  - rini17 7y ago
    To do anything useful across the boundaries, parsing will be involved. Parsing without bounds checking is insecure and will be exploited, period.
- saagarjha 7y ago
  Hardware memory tagging is not a requirement for sandboxing. Actually, hardware memory tagging doesn’t even fully restrict out-of-bounds accesses because it’s granularity is usually larger than a byte.
  - pjmlp 7y ago
    No one is saying it is a requirement, rather that WebAssembly design oversells security by not doing those checks. Even if they would be at word level, it is already an improvement over the actual design.

pjmlp 7y ago

Actually it fails to properly sandbox C derived languages versus what hardware memory tagging like SPARC ADI and ARM are capable of, because it doesn't do bounds checks inside linear memory blocks.

AgentME 7y ago
WebAssembly strongly sandboxes the module from affecting the world outside of it, not from affecting itself. Isn't that the usual use of the word sandbox? The sandbox imposes a boundary between the inside and outside, but it doesn't directly change how things work on the inside. It might be nice to have features for enforcing memory bounds within a module, but I wouldn't call those sandboxing, or call the lack of those features a deficit of the sandbox.
- pjmlp 7y ago
  It is a security deficiency, hence why MSIL that contains certain C++ features is tainted as unsafe by the security verifier. Some other bytecodes like Unisys ClearPath mainframes follow the same approach when using unchecked bounds access. WebAssembly folks just hand wave it as not an issue.
- rini17 7y ago
  To do anything useful across the boundaries, parsing will be involved. Parsing without bounds checking is insecure and will be exploited, period.
saagarjha 7y ago
Hardware memory tagging is not a requirement for sandboxing. Actually, hardware memory tagging doesn’t even fully restrict out-of-bounds accesses because it’s granularity is usually larger than a byte.
- pjmlp 7y ago
  No one is saying it is a requirement, rather that WebAssembly design oversells security by not doing those checks. Even if they would be at word level, it is already an improvement over the actual design.