multi-memory VS spec

Support for multi-memory to deal with multiple memories in Wasm.

> You can do attacks that most people haven't been able to do for 20+ years.

This is a bad and roundabout way to say that vulnerabilities in WebAssembly modules may cause a corruption in their linear memory. Which is absolutely true, but those attacks still matter today (not everyone turns ASLR on) and similar defences also apply. In the future multiple memories [1] should make it much easier to guard against remaining issues. WebAssembly is a lucrative target only because it is so widespread, not because it has horrible security (you don't know what the actually horrible security looks like).

[1] https://github.com/WebAssembly/multi-memory/blob/main/propos...

Thanks! These claims are really interesting.

- WASM has no ASLR.

So I guess if a buffer overrun lets you modify a function pointer, you could replace that function pointer with another pointer to execute different code. As you say, this is hard in native linux programs because ASLR and NX. You need a pointer to some code thats loaded in memory and you need to know where it is. In wasm, the "pointer" isn't a pointer at all. indirect_call takes an index into the jump table. Yes, this makes it easier to find other valid function pointers. But wasm also has some advantages here. Unlike in native code, you can't "call" arbitrary locations in memory. And indirect_call is also runtime typechecked. So you can't call functions with an unexpected type signature. Also (I think) the jump table itself can't be edited by the running wasm module. So there's no way to inject code into the module and run it.

I could be wrong, but I wouldn't be surprised if on balance wasm still ends up safer than native code here. I'm sure there will be more than zero wasm sandbox escapes made by abusing this, but I haven't heard of any so far.

Docs: https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...

- WASM allows writing to 0x0.

You're probably right about this. To be clear, it means if pointers are set to 0 then dereferenced, the program might continue before crashing. And the memory around 0 may be overwritten by an attacker. How bad this is in practice depends on the prevelance of use-after-free bugs (common in C / C++) and what ends up near 0 in memory. In rust, these sort of software bugs seem incredibly rare. And I wouldn't be surprised if wasm compilers for C/C++ start making a memory deadzone here - if they aren't doing that already.

- wasm can easily overflow buffers

Sure, but so can native C code. And unlike native code, wasm can't overflow buffers outside of the data section. So you can't overwrite methods or modify the memory of any other loaded modules. So on net, wasm is still marginally safer than native code here. If you're worried about buffer overflows, use a safer language.

- wasm doesn't have the concept of read-only memory

Interesting! I can see this definitely being useful for system libraries like mmap. This would definitely be nice to have, and it looks like the wasm authors agree with you.

https://github.com/WebAssembly/multi-memory/issues/15

There are stray references to the concept of multiple address spaces (or 'memories') in the wasm spec at present, and I recall at one point you may have always been passing 'memory #0' to your load/store opcodes. It looks like people are still working on that as the solution.

https://github.com/WebAssembly/multi-memory

It's not segmented, so no... or rather, not yet.

The wasm spec already accommodates to some extent the notion of multiple "memories" (i.e. distinct flat heaps), although it only allows for one in practice:

https://webassembly.github.io/spec/core/syntax/modules.html#...

And there's an active proposal to allow for multiple memories:

https://github.com/WebAssembly/multi-memory/blob/main/propos...

In an environment like that, you'd need full-fledged pointers to carry both the memory index and the offset; and then you might want a non-fat "pointer to same memory" alternative for perf. Might as well call them far and near.

You can parse many things from this file, what are you trying to extract?

https://github.com/WebAssembly/spec/blob/main/document/core/...

Still strikes me as super sad JS never got SIMD support. It seemed like there were some strong candidate specs. On Node there are some add-on npm libraries that implement.

My understanding was the main protest was that we would get wasm & some certain implementers said they wanted to focus their energy on wasm.

That was well over half a decade ago & wasm is still in incredible infancy, with basically only statically linked capabilities in the spec.

Wasm SIMD proposal itself only merged into wasm in November 2021. https://github.com/WebAssembly/spec/pull/1391

It seems really unfortunate to have decided to keep JS the slow inferior language.

Blazor and WASM itself (outside of dotnet) are relatively new tools and they already show impressive results. They will keep getting better with every release. E.g. this proposal https://github.com/WebAssembly/spec/blob/main/proposals/simd/SIMD.md which should bring WASM closer to "near native speed". Blazor already started working on it true.

Big fan of this author's work.

They have a Gameboy emulator written in C, which can be compiled to WASM and run in the browser.

https://github.com/binji/binjgb

I learned a lot from the code.

Also I love this project with a bunch of demos in hand-written WebAssembly Text (WAT) format, which is like low-level Lisp that works only with raw memory, numbers, and minimal syntax.

https://github.com/binji/raw-wasm

Then I discovered the same author is quite active in the WebAssembly ecosystem, including specs and tooling. Fascinating stuff!

https://github.com/WebAssembly/spec

https://github.com/WebAssembly/wabt

[The WebAssembly specification (https://webassembly.github.io/spec/) maintains that the standards apply to more than just the browser host, but also to any other compliant host runtime (what the specification refers to as an embedder).

Heya,

(1) Thank you for implementing this in JSC!! I hope they take it, it makes it into Safari, and the tail-call proposal advances.

(2) I don't think you are exactly right about the call stack being observable via thrown exceptions. There's no formal spec for the v3 exceptions proposal yet, but in the documents and tests, there's nothing that would change in WebAssembly core to make the call stack observable. It's true that the proposal amends the JS API (but only the JS API) to describe a traceStack=true option; from Wasm's perspective I understand that's just an ordinary exception that happens to include an externref value (just like any other value) to which Wasm itself attaches no special significance. The engine can attach a stack trace if it wants, but there's no requirement (here) about what that stack trace contains or whether some frames might have been optimized out.

(3) I think the real reason that a Wasm engine can't implicitly make tail calls proper is that the spec tests forbid it, basically because they didn't want the implementation base to split by having some engines perform an optimization that changes the space complexity of a program, which some programs would have started to depend on (the spec tests say: "Implementations are required to have every call consume some abstract resource towards exhausting some abstract finite limit, such that infinitely recursive test cases reliably trap in finite time. This is because otherwise applications could come to depend on it on those implementations and be incompatible with implementations that don't do it (or don't do it under the same circumstances.)" More discussion here: https://github.com/WebAssembly/spec/issues/150

The WASM paper discusses that in the final section: https://github.com/WebAssembly/spec/blob/master/papers/pldi2017.pdf

WebAssembly has a formal specification that includes both operational semantics and natural language-based descriptions of everything in the language. The official repository also has a lot of tests. Besides tests, you should be able to find lots of examples by searching.