wingo / wasm-jit

Test materials for getting JIT support for wizer

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Mention security aspects

josvazg opened this issue · comments

The README does not explain the security implications of this JIT extension work.

One of the main selling points of Web-Assembly is its security model: the host environment is in control, it blocks any function calls to system capabilities that a web assembly module is not allowed to access.

If the code generated is 100% native processor code already, and the runtime just jumps to it directly, it is game over.

A seemingly innocent piece of web-assembly will do. It might not even contain the exploit, that could be some data input coming later, even remotely, so the host runtime will not be able to analyze for possible security issues before it is too late.

On the other hand, if the code generated by this JIT is WASM, then in theory the host should be able to analyze and impose the same restrictions to the freshly generated code as to any other Web Assembly module downloaded off the Internet.

This implies that such resulting new code is still be subject to interpretation, JIT or AOT compilation yet again, to actually run on the target system. This is fine, but is also important to note for performance considerations.

I summary, it would be good to know what uses of this JIT are allowed and how direct native code injection is avoided or secured.

This module has no change to the security model, and indeed can't: the JIT capability (the ability to instantiate an adjunct module from webassembly bytes, and the set of imports/capabilities to provide to the that module) is completely the host's responsibility.