6 ms·

Yeap, so innovative it existed already for decades (virtual machine executing some fixed bytecode).

• superfist 7y ago
  But lack of good and safe isolation was a serious problem
• rapsey 7y ago
  Properly sandboxed VM that you can compile practically any language into?
  • AnIdiotOnTheNet 7y ago
    Yes, it's called DOSBox. Or QEMU with dynamic syscall translation if you want to be real fancy.
  • pjmlp 7y ago
    AS/400 TIMI comes to mind, and CLR as well.
    • Rusky 7y ago
      The CLR is not a great target for running unmodified C code. I suspect that was included in "practically any language."
      • pjmlp 7y ago
        Yeah, Managed C++ and C++/CLI don't exist.
        • Rusky 7y ago
          I was careful to say "unmodified." C++/CLI is hardly that. It's also not at all sandboxed the way wasm is. Why the chip on the shoulder?
          • pjmlp 7y ago
            C++/CLI is just ISO C++ plus a couple of language extensions, you know like the Linux kernel is ISO C plus GCC extensions. I hardly see the difference. No chip on the shoulder, just an old guy that has seen dozens of VMs since the mid-80s, delved into others from earlier decades, which doesn't buy into WASM marketing.
          • int_19h 7y ago
            You're conflating C++/CLI with the MSVC /clr compiler switch. They're distinct. With /clr:pure (which produces CIL only, although it is allowed to use memory-unsafe features like pointers), the entirety of ISO C90 is supported on CLR, with the sole exception of setjmp/longjmp. C++/CLI adds language extensions that allow one to interact with the CLR object model from C++ code. It is only needed if you need to call into the .NET standard library, or other managed libraries - i.e. if your C code is not portable to begin with.
            • Rusky 7y ago
              I'm not conflating anything. And as I said, none of this is sandboxed like WebAssembly so it's hardly a comparison anyway.
              • pjmlp 7y ago
                Neither is WASM that allows for internal corruption due to lack of memory tagging.
    • int_19h 7y ago
      CLR sandbox should not be considered a meaningful security boundary at this point. CAS and partial trust are both officially obsolete. The problem is always complexity. It can be difficult to reason about safety with so many features on bytecode level. There have been exploits using dynamically-generated methods, exception filters, and vararg handling - note the near-lack of any common patterns here other than they're all obscure features of the platform, the security impact of which wasn't fully analyzed. For example, a long time ago, I reported the vararg exploit, which boiled down to the fact that you can have ArgIterator over an argument list containing another ArgIterator, allowing the latter to be mutated via the former. Thus, you can stash away an ArgIterator to the arguments of a function call that has already returned. This is basically the same as having a managed reference to a managed reference, and it's exactly why CLR prohibits this - but they forgot that ArgIterator is also a kind of a managed reference.
      • pjmlp 7y ago
        And WASM remains to be battle tested in the wild, as in the juicy target of millions of black hats out there. Forcing internal corruption of code produced from C compilers (like doing a stack out of bounds data overwrite due to incorrenct params size) is perfectly viable. Yeah the exploit doesn't leave the sandbox, so what. It can still be used to direct the sandboxed code to produce other outcome from the called functions.
  • arcticbull 7y ago
    JVM and CLR.