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:
This issue tracks the design space for applet sandboxing.
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:
Footnotes
Lightweight Fault Isolation ↩