The Bytecode Alliance: Building a secure, composable future for WebAssembly

Post by luke_wagner » Tue, Nov 12, 2019, 6:41 PM UTC

azakai wrote: post #25

Arnavion wrote: post #16

Earlier quoted context omitted.

>specifically since modules don't share their wasm Memory. That means data will be constantly copied between them. It is possible today to have modules import memory from the host, which means the host can provide the same imported memory to multiple modules. Then modules can pass pointers to each other without needing any memcpys. It does require the modules to not tread on each other though, such as by requiring th…

It is possible to share memory in wasm today, yes (we use that to optimize wasm/JS interaction, and wasm/wasm dynamic linking) - and that won't go away, it's a core feature of wasm, you're right. But the specific approach in this article disallows that. The article does mention a possible future extension of multiple wasm modules in a single nanoprocess (the section with "allowing native-style dynamic linking"), and…

Post by JoshTriplett » Tue, Nov 12, 2019, 6:42 PM UTC

Jyaif wrote: post #40

JoshTriplett wrote: post #2

I'm one of the folks working with the Alliance, and I'm incredibly excited about WebAssembly outside the browser. Happy to answer questions. Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data. Imagine supporting a safe plugin API that isn't just for C and languages that FFI to C, but works natively with safe datatypes. Today, if you want to be extens…

Will this work on platforms that do not allow JIT compilation?

Post by jandem » Tue, Nov 12, 2019, 6:42 PM UTC

beefhash wrote: post #34

JoshTriplett wrote: post #15

Earlier quoted context omitted.

The toolchains for building WebAssembly from numerous languages, for one thing. The existence of an LLVM WebAssembly backend helps. (While eventually there were other languages that targeted the JVM, for a long time if you wanted the JVM sandbox you had to write Java.) WebAssembly also provides a fine-grained API surface area; you can run a WebAssembly sandbox with no external functions provided, or just a few. WebAs…

> The existence of an LLVM WebAssembly backend helps. So why aren't people just shipping straight up LLVM intermediate language VMs and instead go through wasm? Incidentally, would you consider wasm as a destination language for virtual machines for obfuscation ? I.e. is it reasonable enough to implement it all in about a week? Plus I fear like the decompilation/disassembly tooling might be there too soon for it to b…

Post by pjmlp » Tue, Nov 12, 2019, 6:45 PM UTC

JoshTriplett wrote: post #39

maxk42 wrote: post #31

Real worried when I see phrases like "secure by default" that this will involve some sort of security certificate or formal verification process which a government or other malicious actor can use as a weapon against its enemies. Is the security limited to sandboxing of the code itself or is there some sort of verification process involved?

The security here is based on sandboxing code and providing limited capabilities. If you're embedding wasm, you choose what capabilities to give the sandbox. For instance, if a game wants to support mods via wasm, it could give the mods APIs to the game world but not to the network or filesystem. A database plugin might have access to interpret a database object handed to it but not exfiltrate data over the network.…

Post by JoshTriplett » Tue, Nov 12, 2019, 6:46 PM UTC

rkeene2 wrote: post #32

One of my next projects is to create a Tcl package for webassembly that will let other extension authors compile their packages targeting WebAssembly and be able to use those compiled binaries on any platform.