Applet sandboxing #759
Description
This issue tracks the design space for applet sandboxing.
| Performance | Sandboxing | Portability | Code size | Memory footprint | |
|---|---|---|---|---|---|
| WebAssembly | Very slow | Full with validation | Full | 20k to 200k (depends on interpreter) | 2k to 200k (depends on interpreter) |
| Pulley | Rather slow | Full without validation | Compiled for Pulley version | Rather high (but being reduced) | Very high (but being fixed) |
| LFI1 | Rather fast | Full with verification | Compiled for target architecture | Rather low? | None? |
| Native | Very fast | None | Compiled for target architecture | None | None |
| CHERI | Very fast | Full | Compiled for target architecture | Very low | Rather low (depends on the ratio of pointers to data) |
Note that for target-specific solutions (LFI, Native, and CHERI), we ideally don't want to link with the platform. We want to use a portable function pointer interface which is not designed yet. Currently, Native is linked to the platform and thus even less portable.
Related issues:
- Support native Rust applets #31
- Interpreter performance and footprint #46
- Explore Wasmtime as an alternative WebAssembly runtime #458