Isolation and security
What keeps a guest in, what it can reach, and how to run code you don't trust.
A Warm64 guest runs inside two layers: the emulated machine, and the WebAssembly sandbox the emulator itself runs in. What the guest can reach beyond them is what you attach to it.
What keeps the guest in
- The emulated machine. Guest code sees only the emulated CPU, its own RAM, and the devices on the command line. It runs as instructions the Interpreter steps through, or as WebAssembly the Just-In-Time compiles from it.
- WebAssembly. The emulator is WebAssembly. It has no access to files, the network or memory outside its own, except through the functions the host, your page or Node, gives it. The browser or Node checks every WebAssembly module, including the ones the Just-In-Time emits, before running it.
- The browser. In a web page, all of this also sits inside the browser's own sandbox for the tab.
What the guest can reach
Exactly what you attach:
| You attach | The guest can |
|---|---|
A disk (-drive) | Read it, and write it unless it's readonly=on or snapshot=on. With a host's openDisk, writes reach the file as they happen. |
| A shared folder | Read and write the files you put in the share. |
-netdev user in Node | Open TCP connections to any address the host can reach: the internet, your local network, and the host's own 127.0.0.1 at 10.0.2.2. |
-netdev user in a browser | Reach only what your relay allows. Without a connector, its TCP connections are refused. |
-netdev socket | Reach the other machines on that hub, and whatever they reach. |
See Networking for the relay and its allow-list.
Running code you don't trust
- In a browser, serve Warm64 from its own origin, one with no logins, tokens or other secrets. Several cores need cross-origin isolation, which also gives a page
SharedArrayBufferand precise timers; keep that origin free of anything worth reading. - In Node, run the process as an unprivileged user or in a container. Leave out
-netdev user, or give the guest a relay with an allow-list. - Disks: attach them with
readonly=onorsnapshot=onwhen the guest shouldn't change them. - Limits: a guest can use all the CPU and memory you give it. Size
-mand-smpfor that. - Updates: the WebAssembly and browser sandboxes are Node's and the browser's. Keep them current.
Status
Warm64 hasn't had an independent security audit, or fuzzing of its device emulation, yet. Treat the layers above as defence in depth, not a guarantee.