Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

hacks.mozilla.org

Post reply on HN
Print view View original

121–130 of 265 posts

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

#121

Post by vanderZwan »

JoshTriplett wrote: post #60
vanderZwan wrote: post #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…

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.

Right, I was being sloppy - I guess was really thinking "memory addresses", not "memory".

Anyway, that's great to hear! Any suggestions for discussions and such that one could follow to see how it develops?

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

#122

Post by AnIdiotOnTheNet »

thrax wrote: post #36
AnIdiotOnTheNet wrote: post #21

Earlier quoted context omitted.

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.

Right, and while you can grow the heap you can't give any of it back, so you can't really dynamically contract your memory without restarting the process.

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

#123

Post by marcosdumay »

bestouff wrote: post #12

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

On the web? If was follow its roadmap, it will become a 1st class web object, interacting with everything else on the same level as JS, HTML, and CSS. That means it will be part of your page, instead of funny images and blurry text with bad UI inside a little box that takes a while to load.

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

#124

Post by BubRoss »

armitron wrote: post #100
pcwalton wrote: post #96

Earlier quoted context omitted.

You seem to be arguing that sandboxing is not a security benefit. On the contrary, sandboxing is maybe the security success story of the past decade.

You missed my point, which is not sandboxing. Webassembly through fine-grained sandboxing promotes software decoherence by amplifying the number of dependencies (since the major downside to working in this fashion is now advertised to be reined in). When the number of dependencies goes up, combinatorial explosion ensures that the state-space is full of possible attacks. Fine-grained sandboxing does not solve this ant…

You might have to give specific examples with wasm in mind instead of talking about ' combinatorial exoplosions in the state space of the amplified meta system '

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

#125

Post by lambda »

JoshTriplett wrote: post #60
vanderZwan wrote: post #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…

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.

Reading through this, this sounds like mostly a capability based architecture, with process isolation replaced with a statically typed bytecode in which you can verify that each module can only use capabilities passed to it.

I was wondering why the focus on copying memory between the processes. It should be possible to make capabilities which represent a pointer and a length (and maybe an access mode), which could be used to give a process direct access to shared memory safely. I don't know if that could be done with low enough overhead for small objects, it's possible that there would need to be a threshold below which you would just copy values to be efficient, but it seems like exploring fat pointer capabilities would be worthwhile.

Memory mapping files or inter-process shared memory is the very coarse-grained version of this, using hardware protection. I feel like it should be possible to do something more efficient and finer grained with pointer capabilities and the static type checking that is done to verify WASM during compilation, but it may be a significant research project of its own.

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

#126

Post by BubRoss »

pjmlp wrote: post #53
vbezhenar wrote: post #37

Earlier quoted context omitted.

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.

Can you link to an example of this exploit? Does javascript suffer from the same problem?

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

#127

Post by baybal2 »

syrusakbary wrote: post #30

First of all, congrats on forming the alliance! > Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data That's what we are working towards on Wasmer, the server side WebAssembly runtime - https://github.com/wasmerio/wasmer In fact, we already have a lot of different language integrations (maintained by us and the community) and our software is the pione…

> First of all, congrats on forming the alliance!

No Google on board, it means no Chrome support

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

#128

Post by pjmlp »

sp332 wrote: post #66
bestouff wrote: post #12

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

Java was wildly successful. It was kicked out of browsers because of its huge attack surface. WASM implementations seem to be going with a sandbox approach out of the gate.

A sandbox mostly used by cryptominers already.

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

#130

Post by pjmlp »

AgentME wrote: post #108
stefan_ wrote: post #81

This is historically the kind of thing that people think is very cool and important, but has turned out to not matter at all. "Languages matter" must be the biggest enduring fallacy of computer programming. It has an obvious corollary in believing processor architectures are important.

The cross-language interoperability of WebAssembly seems practically like a happy side-effect of its design; I don't think it would look much differently at present if it had originally been built to target only C (in a sandboxable way). Most of the article still applies even if you ignore other language support. The first priority for WebAssembly seems to be making things strongly sandboxed.

Actually it fails to properly sandbox C derived languages versus what hardware memory tagging like SPARC ADI and ARM are capable of, because it doesn't do bounds checks inside linear memory blocks.
Post reply on HN