New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃洡 Unmanaged closures #1182

Closed
jfbastien opened this Issue Feb 8, 2018 · 2 comments

Comments

Projects
None yet
4 participants
@jfbastien
Member

jfbastien commented Feb 8, 2018

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Unmanaged Closures
Champion Mark Miller @erights
Status in progress
Phase pre-proposal
Linked issues
Linked repositories github.com/WebAssembly/unmanaged-closures and github.com/erights/wasm-linkage/tree/master/proposals/wasm-linkage

Details

Many applications are extensible frameworks, built to accept third party plugins that add value. For example, Photoshop accepts third party plugins for image transformations. Google EarthEngine is a web-based application that accepts third party plugins for geospatial computation. Many of these plugins are fallible; EarthEngine wishes to protect its own integrity from the potential corruption or compromise of its plugins. At the same time, EarthEngine needs to expose a rich API to these plugins so that they can interact flexibly with EarthEngine. Currently, EarthEngine is written in JavaScript and enforces that its plugins are written in SES (Secure EcmaScript) an ocap subset of JavaScript.

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.

@binji

This comment has been minimized.

Member

binji commented Oct 16, 2018

@binji binji closed this Oct 16, 2018

@erights

This comment has been minimized.

erights commented Oct 16, 2018

Thanks @binji , this is an appropriate move

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.