Live data from Hacker News

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

hacks.mozilla.org

51–60 of 265 posts

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

#51
post #35

Earlier quoted context omitted.

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?

It isn't yet, that work is still in progress. WIT is just the starting point that this would be based on.

(Sorry for the lack of more concrete information, documentation is still in progress.)

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

#53

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.

WebAssembly also has its security issues.

Lack of bounds checking for multiple data accesses mapped to the same linear memory block.

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

#54

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…

Wasmtime is being developed to be usable as just such an embedded runtime. We have some demos of this here: https://github.com/bytecodealliance/wasmtime-demos

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

#55
post #35

Earlier quoted context omitted.

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?

It isn't yet, that work is still in progress. WIT is just the starting point that this would be based on. (Sorry for the lack of more concrete information, documentation is still in progress.)

I see, thanks. Curious to learn more when it is public.

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

#56
I was talking with a colleague today who mentioned that he had looked at WASM for a particular use-case (file-verification IIRC) and had concluded that for now the overhead of copying memory made it run worse than well-written JavaScript. It is also my experience that the overhead of memory copying can really put a damper on performance improvements.

Now, I get that sharing memory is a huge safety issue - it kind of inherently breaks the sandbox, but when I see the "nanoprocesses" bit in the article I worry about death by a thousand paper cuts (lots of tiny WASM module spending more time copying data than processing it). Are there ways/plans to minimize memory copies that don't conflict with the safety concerns?

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

#57

Does this mean we'll also have a mechanism like pledge(2) to assert that the root nanoprocess or any privileged brokers only needs access to certain APIs, and permanently close them? ¹ - https://man.openbsd.org/pledge.2

The WASI and Bytecode Alliance approach is based on capability-based security, granting only the access needed for a module to do its job.

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

#58
The primary use case for WebAssembly is malware.[1] We're probably going to regret letting WebAssembly into the browser. Because vendors won't let it be locked down so much that it can't be used for ads and tracking. Which means it has to allow malware.

[1] https://www.tu-braunschweig.de/Medien-DB/ias/pubs/2019-dimva...

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

#59

And a key point: "Our founding members are Mozilla, Fastly, Intel, and Red Hat" Where are Google, Microsoft and the other big names you would expect?

> Where are Google, Microsoft and the other big names you would expect? Those folks are the incumbents. What do they have to gain from joining? Google especially has developed a colossal amount of tooling in-house that gives it an edge over others; new tech may make the lives of competition easier. Ditto to an extent for MS, though there, I suspect it's more bureaucracy and not seeing anything to gain.

After all MSIL already supported multiple languages, including C++, back in 2001.

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

#60

I was talking with a colleague today who mentioned that he had looked at WASM for a particular use-case (file-verification IIRC) and had concluded that for now the overhead of copying memory made it run worse than well-written JavaScript. It is also my experience that the overhead of memory copying can really put a damper on performance improvements. Now, I get that sharing memory is a huge safety issue - it kind of…

There will be ways to memory-map files, share memory between modules, and otherwise avoid copying memory unnecessarily.

Shared memory doesn't break the sandbox. Sharing all memory by default would, but controlled sharing of specific memory doesn't. Think of it like inter-process shared memory, rather than threads sharing an entire address space.

Post reply on HN