Live data from Hacker News

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

hacks.mozilla.org

31–40 of 265 posts

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

#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?

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

#33

I saw a comment about this on HN before, forgot who it was by. But it was interesting, someone mentioned the spec for WebAssembly is generic enough to apply outside of the web. I'm suspecting we'll see languages converting on node.js a la web assembly for back-end logic in your preferred language, but in any runtime this includes NodeJS but also excludes it as we see future runtimes. What's your view on this? Also, A…

> It would also be interesting to have an embedded WebAssembly plugin runtime, much like Lua is used all over now that you mention all those examples.

Completely! Here are some examples on how to embed Wasm in different languages:

* Python - https://github.com/wasmerio/python-ext-wasm

* PHP - https://github.com/wasmerio/php-ext-wasm

* Go - https://github.com/wasmerio/go-ext-wasm

* .Net - https://github.com/migueldeicaza/WasmerSharp

...and many more! (just check the Wasmer repo)

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

#34

Don't take it bad, but it looks like the java launch a (long) while ago. What makes wasm better than java ?

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 be a real viable option, but maybe nobody's been working on that yet.

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

#35
post #23

Earlier quoted context omitted.

Interesting! Is that written up somewhere public?

Some of it; see https://hacks.mozilla.org/2019/08/webassembly-interface-type... for the starting point that this will be based on.

Oh, where? I don't think I see anything about controlled memory sharing there, but I guess I missed it. Which section is it in?

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

#36
post #7

In my opinion this is a fascinating approach, and it may end up transforming our industry. But the main question I've had is how big the overhead is, specifically since modules don't share their wasm Memory. That means data will be constantly copied between them. Compared to regular static or even dynamic linking, that may be a noticeable slowdown.

Last I checked WebAssembly still didn't have a way of actually freeing memory it has allocated either.

You give it a heap. It doesn't allocate memory. It may allocate within its own heap, using whatever allocator/gc strategy it inherits from it's host language.

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

#37

Don't take it bad, but it looks like the java launch a (long) while ago. What makes wasm better than java ?

Java failed to deliver safe sandbox. Browsers finally booted it because of numerous vulnerabilities. For me wasm looks exactly like another JVM attempt, but it's a good thing, because the idea is good, we just need better implementation.

Now if I don't need sandbox, it's going to be a tougher sell. But who knows, may be it'll outperform JVM on bare metal some day.

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

#38
post #7

In my opinion this is a fascinating approach, and it may end up transforming our industry. But the main question I've had is how big the overhead is, specifically since modules don't share their wasm Memory. That means data will be constantly copied between them. Compared to regular static or even dynamic linking, that may be a noticeable slowdown.

Last I checked WebAssembly still didn't have a way of actually freeing memory it has allocated either.

I thought that was the host's work. You import a function that does it. If we're talking about shared objects. Your own module's memory is managed by you (or your language's runtime)

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

#39
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.

We're providing mechanisms here, not identity-based policies.

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

#40

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 reply on HN