3 ms·

WebAssembly doesn't have access to the high-resolution timers needed for Spectre attacks unless the host process intentionally grants that capability to the san

WebAssembly doesn't have access to the high-resolution timers needed for Spectre attacks unless the host process intentionally grants that capability to the sandboxed code. See this quote from the paper you linked: """ Our attacks extend Google’s Safeside [24] suite and, like the Safeside POCs, rely on three low-level instructions: The rdtsc instruction to measure execution time, the clflush instruction to evict a particular cache line, and the mfence instruction to wait for pending memory operations to complete. While these instructions are not exposed to Wasm code by default, we expose these instructions to simplify our POCs. """ The security requirements of shared-core hosting that want to provide a full POSIX-style API are unrelated to the standard use of WebAssembly as an architecture-independent intermediate bytecode for application-specific plugins. 'gf000 correctly notes that WebAssembly's security properties are basically identical to any other interpreter, and there's many options for bytecodes (or scripting languages) that can do some sort of computation without any risk of a sandbox escape. WebAssembly is distinguished by being a good generic compilation target and being easy to write efficient interpreters/JITs for.

pjmlp 2y ago
WebAssembly doesn't exist in isolation, it needs host process to actually execute. So whatever security considerations are to be taken from bytecode semantics, they are useless in practice, which keeps being forgotten by its advocates. As they, and you point out, "WebAssembly's security properties are basically identical to any other interpreter,..." The implementation makes all the difference.
- jmillikin 2y ago
  The WebAssembly bytecode semantics are important to security because they make it possible to (1) be a compilation target for low-level languages, and (2) implement small secure interpreters (or JITs) that run fast enough to be useful. That's why WebAssembly is being so widely implemented. Java was on a path to do what WebAssembly is doing now, back in the '90s. Every machine had a JRE installed, every browser could run Java applets. But Java is so slow (and its sandboxing design so poor) that the world gave up on Java being able to deliver "compile once run anywhere". If you want to take a second crack at Sun's vision, then you can go write your own embedded JVM and try to convince people to write an LLVM backend for it. The rest of us gave up on that idea when applets were removed from browsers for being a security risk.
  - pjmlp 2y ago
    People talk all the time about Java, while forgeting such king of polyglot bytecodes exist since 1958, there are others that would be quite educating to learn about instead of always using Java as an example.
    - jmillikin 2y ago
      Ok, show me a bytecode from the 60s (or 90s!) to which I can compile Rust or Go and then execute with near-native performance with a VM embedded in a standard native binary. The old bytecodes of the 20th century were designed to be a compilation target for a single language (or family of closely-related languages). The bytecode for Erlang is different from that of Smalltalk is different from that of Pascal, and that's before you start getting into the more esoteric cases like embedded Forth. The closest historical equivalent to today's JVM/CLR/WebAssembly I can think of is IBM's hardware-independent instruction set, which I don't think could be embedded and definitely wasn't portable to microcomputer architectures.
      - pjmlp 2y ago
        The extent of how each bytecode was used doesn't invalidate their existence. Any bytecode can be embedded, it is a matter of implementation. > The Architecture Neutral Distribution Format (ANDF) in computing is a technology allowing common "shrink wrapped" binary application programs to be distributed for use on conformant Unix systems, translated to run on different underlying hardware platforms. ANDF was defined by the Open Software Foundation and was expected to be a "truly revolutionary technology that will significantly advance the cause of portability and open systems",[1] but it was never widely adopted. https://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut... > The ACK's notability stems from the fact that in the early 1980s it was one of the first portable compilation systems designed to support multiple source languages and target platforms https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit > More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. https://news.microsoft.com/2001/10/22/massive-industry-and-developer-support-for-microsoft-net-on-display-at-professional-developers-conference-2001/ https://news.microsoft.com/2001/10/22/massive-industry-and-d... Plenty more examples available to anyone that cares to dig what happened after UNCOL idea came to be in 1958. Naturally one can always advocate that since 60 years of history have not provided that very special feature XYZ, we should now celebrate WebAssembly as the be all end all of bytecode, as startups with VC money repurpose old ideas newly wrapped.

pjmlp 2y ago

WebAssembly doesn't exist in isolation, it needs host process to actually execute. So whatever security considerations are to be taken from bytecode semantics, they are useless in practice, which keeps being forgotten by its advocates. As they, and you point out, "WebAssembly's security properties are basically identical to any other interpreter,..." The implementation makes all the difference.

jmillikin 2y ago
The WebAssembly bytecode semantics are important to security because they make it possible to (1) be a compilation target for low-level languages, and (2) implement small secure interpreters (or JITs) that run fast enough to be useful. That's why WebAssembly is being so widely implemented. Java was on a path to do what WebAssembly is doing now, back in the '90s. Every machine had a JRE installed, every browser could run Java applets. But Java is so slow (and its sandboxing design so poor) that the world gave up on Java being able to deliver "compile once run anywhere". If you want to take a second crack at Sun's vision, then you can go write your own embedded JVM and try to convince people to write an LLVM backend for it. The rest of us gave up on that idea when applets were removed from browsers for being a security risk.
- pjmlp 2y ago
  People talk all the time about Java, while forgeting such king of polyglot bytecodes exist since 1958, there are others that would be quite educating to learn about instead of always using Java as an example.
  - jmillikin 2y ago
    Ok, show me a bytecode from the 60s (or 90s!) to which I can compile Rust or Go and then execute with near-native performance with a VM embedded in a standard native binary. The old bytecodes of the 20th century were designed to be a compilation target for a single language (or family of closely-related languages). The bytecode for Erlang is different from that of Smalltalk is different from that of Pascal, and that's before you start getting into the more esoteric cases like embedded Forth. The closest historical equivalent to today's JVM/CLR/WebAssembly I can think of is IBM's hardware-independent instruction set, which I don't think could be embedded and definitely wasn't portable to microcomputer architectures.
    - pjmlp 2y ago
      The extent of how each bytecode was used doesn't invalidate their existence. Any bytecode can be embedded, it is a matter of implementation. > The Architecture Neutral Distribution Format (ANDF) in computing is a technology allowing common "shrink wrapped" binary application programs to be distributed for use on conformant Unix systems, translated to run on different underlying hardware platforms. ANDF was defined by the Open Software Foundation and was expected to be a "truly revolutionary technology that will significantly advance the cause of portability and open systems",[1] but it was never widely adopted. https://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut... > The ACK's notability stems from the fact that in the early 1980s it was one of the first portable compilation systems designed to support multiple source languages and target platforms https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit > More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. https://news.microsoft.com/2001/10/22/massive-industry-and-developer-support-for-microsoft-net-on-display-at-professional-developers-conference-2001/ https://news.microsoft.com/2001/10/22/massive-industry-and-d... Plenty more examples available to anyone that cares to dig what happened after UNCOL idea came to be in 1958. Naturally one can always advocate that since 60 years of history have not provided that very special feature XYZ, we should now celebrate WebAssembly as the be all end all of bytecode, as startups with VC money repurpose old ideas newly wrapped.