|
|
|
|
|
by himata4113
5 days ago
|
|
I do specifically that and abandoned WASI in favor of freestanding with shared memory regions + PIC memory region. It works today and is easily extensible as well as increadibly fast, sandboxing is not as strong since modules can read code they don't own and modify data they do not own, but splitting modules into "trusted" and "untrusted" largely mitigated those issues as memory has write bit stripped for execution during untrusted modules, only allowing data they own to be modified. Sensitive data lives outside the runtime and has to be fetched with (slower) host methods. Point being, if you rely on a non standard specification of developer defined wasi api subspec you might as well just go with freestanding. |
|
Precisely this. The whole endeavor has been disappointing. I'd love to build support for WASI but realistically it's far simpler for all parties just to do something custom, which feels wrong. I get that it's only 0.3 but it's advancing far too slowly for my tastes. I just don't know who it's for right now.