WebAssembly

multi-memory

WebAssembly2020–2025

WebAssembly / multi-memory · Archived

multi-memory

Multiple per-module memories for Wasm

Web Development

Explore on GitHub Read Hacker News discussions

11Distinct people

11Mentions

0Explicit recommenders

139GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Multiple per-module memories for Wasm

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year11 dated mentions

Observed mentions: 2020-01-19 16:56:37 UTC to 2025-09-17 19:57:22 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	2	2
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	3	3
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	2	2
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	2	2
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	2	2

What Hacker News says

11 sources

titzer·Sep 17, 2025

There has been a discussion (https://github.com/WebAssembly/multi-memory/issues/45) on the toolchain support, but I'm not sure if there have been steps to use multiple address spaces to support Wasm multi-memory in LLVM yet.

In WASM 3.0 Completed

flohofwoe·Jan 19, 2025

There is, but then you'd need to declare the entire WASM heap as a single SharedArrayBuffer. It only makes sense for shared-memory multithreading (but not that support for SharedArrayBuffer only works in 'cross-origin isolated' contexts). There is a related 'multiple memories' proposal btw: https://github.com/WebAssembly/multi-memory

In WASM GC isn't ready for realtime graphics

actionfromafar·Nov 28, 2024

Interesting! https://github.com/WebAssembly/multi-memory/blob/main/propos... The scaling point is what I was thinking of. "As long as Wasm memories are limited to 32 bit address space, there is no way to scale out of 4 GB memory efficiently. Multiple memories at least provide an efficient workaround until 64 bit memories become available (which may still take a while)." So pretty similar to launching several processes on 32 bit NT or Linux, each having their own memory space.

In Revisiting the DOS Memory Models

sitkack·Nov 27, 2024

Wasm64 will soon be everywhere if you want more than 4GB of address space. No, I was saying you could simulate larger heaps by selectively paging data memory in and out, you would still need a way to represent your max heap size. Wasm also supports multimemories, https://github.com/WebAssembly/multi-memory

In Revisiting the DOS Memory Models

lifthrasiir·Sep 14, 2023

> 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 still 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 and relatively young, not because it has horrible security (you don't know how the actually horrible security looks like). [1] https://github.com/WebAssembly/multi-memory/blob/main/propos...

In WASI Support in Go

josephg·Aug 5, 2023

Thanks! These claims are really interesting. - WASM has no ASLR. If I understand correctly, the attack vector here is that if a buffer overrun lets you modify a function pointer, you could replace that function pointer with another pointer to have the program execute different code. As you say, this is hard in native linux programs because of ASLR. 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 tab

Read the rest

le itself can't be edited by the running wasm module. So there's no way to inject code into the module and run it. You only have access to call the already-loaded functions that are in the jump table. And amongst those, you can only substitute one with a matching type signature. I agree - ASLR could help here. But it still doesn't sound super easy to exploit. That said, it might be much easier to exploit this with wasi when the function table is filled with unix syscalls. 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

In WASI: WebAssembly System Interface

kevingadd·Aug 23, 2022

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 before it was dropped from 1.0. It looks like people are still working on that as the solution. https://github.com/WebAssembly/multi-memory > Add a memory index to all memory-related instructions. > Loads and stores have the memop field, in which we can allocate a bit indicating a memory index immediate in the binary format. > All other memory instruction already have a memory index immediate (which currently has to be 0).

In Accessing WebAssembly reference-typed arrays from C++

int_19h·Jun 28, 2022

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.

In WebAssembly and C++

keithwinstein·Apr 19, 2022

The multi-memory proposal is your best bet for this: https://github.com/WebAssembly/multi-memory It's supported in Wasmtime, WAVM, and WABT and wasm2c, and not much else so far (https://webassembly.org/roadmap/).

In WebAssembly 2.0 First Working Draft

Avi-D-coder·May 14, 2020

Why prefer 64bit pointers over multiple memory address spaces (https://github.com/WebAssembly/multi-memory)? Your CPU has to do a lot of work to keep pretending it's memory is flat, If we give up that pretense you can optimize cache utilization and multiplex multiple WASM threads onto a single OS thread without allowing specter.

In Up to 4GB of Memory in WebAssembly

cdcarter·Jan 19, 2020

Good news! WebAssembly has community group projects setup for both multithreading [0] and multi-memories [1] which would allow a module to both define a memory space and also import a shared one. There are so many parties interested in wasm, there are a ton of inflight proposals and extensions to get it beyond the mvp stage. [0]: https://github.com/WebAssembly/threads [1]: https://github.com/WebAssembly/multi-memory

In Standalone WebAssembly games using I/O devices