Syscall API

Two relevant kinds of system calls for Wetware:

1. "Classic" syscalls to the OS
2. Syscalls to the cluster

Cluster Syscalls

Cluster syscalls are handled through Wetware's Host capability.

Outstanding Questions

How do we pass the Host capability int the WASM process?

The main constraint here is efficiency. We should avoid copying data between the host and guest environment.

The most promising avenue would be to wrap api.Memory in a type that satisfies capnp's rpc.Transport interface. This would allow the host to read/write directly to/from the WASM runtime, at the cost of requiring guest code to have a functioning capnp RPC implementation (if it wants to make cluster syscalls).

How do we share data between processes

(This is stream-of-consciousness; don't worry if it doesn't make sense)

At some point, I'd like to have native support for BEAM-like immutable data with generational GC. The idea is that the WASM process's memory would hold the ref until it is shared with another process, at which point custody of the underlying memory-[]byte would be trasnferred to the host runtime. In other words, we would just hand off to the main Go GC.

Obviously, different languages are going to have different data representations, so we should use capnp as a standard encoding. Of course, this means most languages would require some indirection to map their native types onto Wetware data-types. We can probably get away with making such indirection an application concern.

Ultimately, we can add support for something like CapML, which would be able to compute over capnp datatypes (including capabilities!!) natively.

OS Syscalls

OS syscalls are about interacting with the host OS (e.g. linux). As a general rule, we want to avoid this for two reasons:

1. Security (enough said)
2. Programming paradigm.
   • The whole point of wetware is to use a higher-level programming paradigm.
   • files/sockets/etc as anti-pattern in distributed systems
     (c.f. want allocentric viewpoint, not egocentric).

Outstanding Questions

How much access to the host OS should processes have?

What is the smallest set of syscalls we can/should support? How far can we go in restricting the runtime environment? The browser might be a good model to bear in mind, here.

How do we deal with applications that want to bind sockets?

Should we be able to run web servers in Wetware procs (probably yes)? How can we provide capability-oriented security in such cases? Sandstorm is a good model for this. It seems like we might be able to use WASI in conjunction with requiring the caller to pass in binder/conn capabilities, or something similar.

WASI

WASI is the de facto standard for the OS syscall interface. It's basically "syscalls for WASM".

Bottom Line: WASI provides standard interfaces for a bunch of syscalls, some of which we probably want (crypto/rand, time, …). However, we probably don't want to support most of them.

What I Like

• Allows standard libraries of most languages to "just work"
  • rand
  • time
  • fopen
  • sockets, envvars, args, etc

What I Don't Like

• Very alpha
• Wetware wants to be a restricted environment
  • Think "browser"
  • Avoid metacomputing
• Lots of shims w/ planned deprecation
  • "Separate metacomputing form computing"
    • WASM wants to be capability-oriented => "you don't need FS"
  • Shims included as an upgrade path for existing systems
• Development seems stalled, maybe? Unclear what will eventually be stable, and when. Risky to adopt.

Where I Think we can Use it

Wazero gives us a reference implementation, which we can modify to suit our needs. It seems like most (all?) implementations can be modified through the sysCtx.

Key changes might include:

1. Disabling FS access.
   1. Disabled by defualt, unless we pass fs to module builder?
   2. Consider supporting heavily-restricted local storage?
      • Mount to empty tempdir
      • Storage is volatile; destroyed when process dies
      • Useful for cacheing / offloading data from memory
      • Consider bitswap integration
      • Think carefully. Do we really need/want this?
2. Disable Args / Environment
   1. Allow users to pass in capabilities instead.
3. Disable proc_exit?
   • I think this can be done natively in WASM, using traps.
   • I also think certain WASM bindings rely on this, but it's hacky; would rather start from a clean slate.