Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
🛤 Unmanaged closures #6
This is a tracking issue for a post-MVP feature
Wasm would enable EarthEngine to be written in C++, and to accept plugins written in C++. Wasm already provides all the protection mechanisms needed so they can be linked together in one OS address space and interact via full speed function calls. EarthEngine would reside in one compartment (a set of wasm modules linked together sharing the same memories and tables --- see below) and each plugin in another. EarthEngine would export the functions it wishes to make available to its plugins, and instantiate each plugin only with access to these exports. The code within each compartment is as vulnerable to buffer overflow or other memory corruption as we expect of C++. But this separation prevents a memory corruption vulnerability in a plugin from compromising EarthEngine.
In this sense, each wasm compartment resembles an OS process with its separate address space and descriptors; and an inter-compartment call resembles an IPC. However, the cost of the context switch between these protection domains is simply the cost of code in one wasm compartment calling an imported function that was exported by another linked wasm compartment.
This demonstrates that wasm already provides the safety needed for such protection. But it lacks the needed expressiveness.