You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When loading a WASM plugin, it is the runtime's responsibility to verify the plugin implements the expected functions. The code for the runtimes we generate intentionally do not assume plugins implement any of the fp_export! functions, because there's no way for us to enforce this anyway. Marking the functions as optional also has a practical advantage from a versioning perspective: When a new function is added to the protocol, the runtime may still wish to accept plugins that only implement an older version of the protocol. By marking the functions as optional, this decision is left to the implementor of the runtime.
However, there's a big caveat in all this: Even if a plugin exports a symbol for an expected function, there's no way to tell if the function signature actually matches. If the plugin implements a backwards-incompatible version of the function signature, the only way to find out is when the function crashes on invocation.
To improve this experience, we may wish to embed metadata in the plugins that list which functions, including their signatures, are actually implemented. The runtimes could then verify this metadata is as expected when the plugin gets loaded.
Then we could also take it a step further by marking functions as required in the protocol definition and letting the runtime outright reject plugins that fail to implement those.
The text was updated successfully, but these errors were encountered:
When loading a WASM plugin, it is the runtime's responsibility to verify the plugin implements the expected functions. The code for the runtimes we generate intentionally do not assume plugins implement any of the
fp_export!
functions, because there's no way for us to enforce this anyway. Marking the functions as optional also has a practical advantage from a versioning perspective: When a new function is added to the protocol, the runtime may still wish to accept plugins that only implement an older version of the protocol. By marking the functions as optional, this decision is left to the implementor of the runtime.However, there's a big caveat in all this: Even if a plugin exports a symbol for an expected function, there's no way to tell if the function signature actually matches. If the plugin implements a backwards-incompatible version of the function signature, the only way to find out is when the function crashes on invocation.
To improve this experience, we may wish to embed metadata in the plugins that list which functions, including their signatures, are actually implemented. The runtimes could then verify this metadata is as expected when the plugin gets loaded.
Then we could also take it a step further by marking functions as required in the protocol definition and letting the runtime outright reject plugins that fail to implement those.
The text was updated successfully, but these errors were encountered: