6 ms·
"Run a fast, sandboxed bytecode outside of the sandbox by compiling it into a binary" so just a binary. I'm not sure I understand why you would use wasm here.
by mises 7y ago
"Run a fast, sandboxed bytecode outside of the sandbox by compiling it into a binary" so just a binary. I'm not sure I understand why you would use wasm here. No one writes wasm; you compile to it (usually from llvm ir). Why couldn't you just go straight from llvm ir to a binary; skip the wasm? I suspect I'm missing something here, but it doesn't seem to make sense.
- chr1 7y agoThat way the same binary could run on machines with different architectures. There is also work in progress to define common system api for wasm, which would allow to run the same binary on any platform.
- jmisavage 7y agoFor any other reader, the common system API that chr1 speaks of is called WASI. Mozilla's announcement of it is here: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...
- techntoke 7y agoBecause WASM is already bad for user security, they want to make it worse.
- kbumsik 7y ago> WASM is already bad for user security Any source?
- techntoke 7y agoYou are running a binary and you have to trust the sandbox. Hasn't worked so well for web browsers even with JavaScript.
- weego 7y agoAlso didn't work well for Flash.
- ineedasername 7y agoHere's one: https://www.fastly.com/blog/hijacking-control-flow-webassembly https://www.fastly.com/blog/hijacking-control-flow-webassemb... I'm not sure any of this is any worse than javascript though.
- pjmlp 7y agoInternal memory corruption caused by out of bounds accesses, in case the code was generated from C derived languages, as it doesn't provide memory tagging.
- sanxiyn 7y agoWebAssembly is portable, stable, and well-specified. LLVM IR is not portable (it is platform-specific), not stable (it changes between LLVM versions), and not well-specified (especially around undef). Therefore, WebAssembly is a good distribution format, LLVM IR is not.
- MBCook 7y agoWe already have a portable, stable, well specified cross platform language. It’s called Java. What extra benefit does this provide, except avoiding Oracle?
- jchw 7y agoOh good point, we can just embed the JVM into browsers instead. WebAssembly’s cancelled everyone! Jokes aside, why are you comparing these two very different virtual machines? WASM is a general purpose VM, JVM is not. For example, you won’t find a Rust JVM target any time soon. (Not to suggest that the JVM is strictly limited to Java, it isn’t obviously, but it is not nearly as suited to being a target for lower level languages. Also, the security model is very different.)
- gravypod 7y agoI think it is experimentally possible to target Rust -> LLVM -> JVM using this project https://github.com/davidar/lljvm https://github.com/davidar/lljvm
- jchw 7y agoIn fact there’s almost certainly more ways, too. You could probably transpile WASM to JVM bytecode. These things are most useful when you already are in the JVM anyways, I can’t imagine most people writing software in pure Rust would jump for this, especially given that WASM has a lot to offer for this use case already and has good momentum. I see it as a better fit, with useful security guarantees and a simple design.
- writepub 7y agoBecause LLVM IR is CPU-Arch specific. For instance, IR for x86 cannot be used on ARM CPUs, which is also the reason why Apple's bitcode representation intended to make apps portable, doesn't cross the iOS (ARM) <--> MacOs (x64) boundary, unless ARM ISA emulation is happening in Mac (like in Marzipan?)
- vijaybritto 7y agoIf your native code runs on different platforms, you can compile it once to wasm and it will run in the same speed on all of those platforms.