We're working on that. We want to make it possible for modules to share memory in a controlled way, without giving access to their entire address space.

Other than that, I wonder if nested page tables that are normally used for virtualization can be used to separate address spaces within a process.

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

It is possible today to have modules import memory from the host, which means the host can provide the same imported memory to multiple modules. Then modules can pass pointers to each other without needing any memcpys.

It does require the modules to not tread on each other though, such as by requiring them to have distinct static offsets (poor man's linking), or by requiring them to be PIC / compiled with relocation info so that they can be relinked by the host loader.

It doesn't seem to me from reading TFA that this is going away, merely that there are planning to add alternatives to make it more fine-grained.

The article does mention a possible future extension of multiple wasm modules in a single nanoprocess (the section with "allowing native-style dynamic linking"), and JoshTriplett mentions in another comment some future ideas of sharing parts of memory but not all. Those things will compromise the strict initial requirement of no shared memory, and improve performance.

Those are the interesting questions for me - is not sharing memory too much overhead, and if it is, is there a way to relax that which preserves enough security with enough performance.

There's still a lot more details to figure out, of course, but that's true for wasm dynamic (shared-everything) linking in general.

Starting with speed and trying patch in security doesn’t seem to make things actually secure.

  $ strace /bin/ls 2>&1 | grep brk
  brk(NULL)                               = 0x55fb032b3000
  brk(NULL)                               = 0x55fb032b3000
  brk(0x55fb032d4000)                     = 0x55fb032d4000

  $ ktrace /bin/ls >/dev/null
  $ kdump | grep brk | wc -l     
         0
  $ kdump | grep mmap | wc -l
       130