3 ms·

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) imple

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.
    - jmillikin 2y ago
      > The extent of how each bytecode was used doesn't invalidate their existence. It does, because uptake is the proof of suitability to purpose. There's no credit to just being first to think of an idea, only in being first to implement it well enough that everyone wants to use it. > Any bytecode can be embedded, it is a matter of implementation. Empty sophistry is a poor substitute for thought. Are you going to post any evidence of your earlier claim, or just let it waft around like a fart in an elevator? In particular, your reference to ANDF is absurd and makes me think you're having this discussion in bad faith. I remember ANDF, and TenDRA -- I lost a lot of hours fighting the TenDRA C compiler. Nobody with any familiarity with ANDF would put it in the same category as WebAssembly, or for that matter any other reasonable bytecode. For anyone who's reading this thread, check out the patent (https://patents.google.com/patent/EP0464526A2/en https://patents.google.com/patent/EP0464526A2/en) and you'll understand quickly that ANDF is closer to a blend of LLVM IR and Haskell's Cmm. It's designed to be used as part of a multi-stage compiler, where part of the compiler frontend runs on the developer system (emitting ANDF) and the rest of the frontend + the whole backend + the linker runs on the target system. No relationship to WebAssembly, JVM bytecode, or any other form of bytecode designed to be executed as-is with predictable platform-independent semantics. > More than 20 programming tools vendors offer some 26 programming languages > — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. I want to see you explain why you think the CLR pre-dates the JVM. Or explain why you think C++/CLI is the same as compiling actual standard C/C++ to WebAssembly. > 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. Yes, it is in fact normal to celebrate when advances in compiler implementation, security research and hardware performance enable a new technology that solves many problems without any of the downsides that affected previous attempts in the same topic. If you reflexively dislike any technology that is adopted by startups, and then start confabulating nonsense to justify your position despite all evidence, then the technology isn't the problem.
      - pjmlp 2y ago
        > It does, because uptake is the proof of suitability to purpose. There's no credit to just being first to think of an idea, only in being first to implement it well enough that everyone wants to use it. Depends on how the sales pitch of those selling the new stack goes. > Empty sophistry is a poor substitute for thought. Are you going to post any evidence of your earlier claim, or just let it waft around like a fart in an elevator? Creative writing, some USENET flavour, loving it. > In particular, your reference to ANDF is absurd and makes me think you're having this discussion in bad faith. I remember ANDF, and TenDRA -- I lost a lot of hours fighting the TenDRA C compiler. Nobody with any familiarity with ANDF would put it in the same category as WebAssembly, or for that matter any other reasonable bytecode. It is a matter of prior art, not what they achieved in practice. > I want to see you explain why you think the CLR pre-dates the JVM. Or explain why you think C++/CLI is the same as compiling actual standard C/C++ to WebAssembly. I never written that the CLR predates the JVM, where is that can you please point us out? C++/CLI is as standard C and C++, as using emscripten clang extensions for WebAssembly integration with JavaScript. But I tend to forget at the eyes of FOSS folks, clang and GCC language extensions are considered regular C and C++, as if defined by ISO themselves. > Yes, it is in fact normal to celebrate when advances in compiler implementation, security research and hardware performance enable a new technology that solves many problems without any of the downsides that affected previous attempts in the same topic. Naturally, when folks are honest about the actual capabilities and the past they build upon. I love WebAssembly Kubernetes clusters reinventing application servers, by the way, what a cool idea!

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.
  - jmillikin 2y ago
    > The extent of how each bytecode was used doesn't invalidate their existence. It does, because uptake is the proof of suitability to purpose. There's no credit to just being first to think of an idea, only in being first to implement it well enough that everyone wants to use it. > Any bytecode can be embedded, it is a matter of implementation. Empty sophistry is a poor substitute for thought. Are you going to post any evidence of your earlier claim, or just let it waft around like a fart in an elevator? In particular, your reference to ANDF is absurd and makes me think you're having this discussion in bad faith. I remember ANDF, and TenDRA -- I lost a lot of hours fighting the TenDRA C compiler. Nobody with any familiarity with ANDF would put it in the same category as WebAssembly, or for that matter any other reasonable bytecode. For anyone who's reading this thread, check out the patent (https://patents.google.com/patent/EP0464526A2/en https://patents.google.com/patent/EP0464526A2/en) and you'll understand quickly that ANDF is closer to a blend of LLVM IR and Haskell's Cmm. It's designed to be used as part of a multi-stage compiler, where part of the compiler frontend runs on the developer system (emitting ANDF) and the rest of the frontend + the whole backend + the linker runs on the target system. No relationship to WebAssembly, JVM bytecode, or any other form of bytecode designed to be executed as-is with predictable platform-independent semantics. > More than 20 programming tools vendors offer some 26 programming languages > — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. I want to see you explain why you think the CLR pre-dates the JVM. Or explain why you think C++/CLI is the same as compiling actual standard C/C++ to WebAssembly. > 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. Yes, it is in fact normal to celebrate when advances in compiler implementation, security research and hardware performance enable a new technology that solves many problems without any of the downsides that affected previous attempts in the same topic. If you reflexively dislike any technology that is adopted by startups, and then start confabulating nonsense to justify your position despite all evidence, then the technology isn't the problem.
    - pjmlp 2y ago
      > It does, because uptake is the proof of suitability to purpose. There's no credit to just being first to think of an idea, only in being first to implement it well enough that everyone wants to use it. Depends on how the sales pitch of those selling the new stack goes. > Empty sophistry is a poor substitute for thought. Are you going to post any evidence of your earlier claim, or just let it waft around like a fart in an elevator? Creative writing, some USENET flavour, loving it. > In particular, your reference to ANDF is absurd and makes me think you're having this discussion in bad faith. I remember ANDF, and TenDRA -- I lost a lot of hours fighting the TenDRA C compiler. Nobody with any familiarity with ANDF would put it in the same category as WebAssembly, or for that matter any other reasonable bytecode. It is a matter of prior art, not what they achieved in practice. > I want to see you explain why you think the CLR pre-dates the JVM. Or explain why you think C++/CLI is the same as compiling actual standard C/C++ to WebAssembly. I never written that the CLR predates the JVM, where is that can you please point us out? C++/CLI is as standard C and C++, as using emscripten clang extensions for WebAssembly integration with JavaScript. But I tend to forget at the eyes of FOSS folks, clang and GCC language extensions are considered regular C and C++, as if defined by ISO themselves. > Yes, it is in fact normal to celebrate when advances in compiler implementation, security research and hardware performance enable a new technology that solves many problems without any of the downsides that affected previous attempts in the same topic. Naturally, when folks are honest about the actual capabilities and the past they build upon. I love WebAssembly Kubernetes clusters reinventing application servers, by the way, what a cool idea!