9 ms·
With the advent of WASM, the mentioned sandbox is no more language specific. Threads & garbage collection are coming soon to WASM, which should open up most rel
by writepub 8y ago
With the advent of WASM, the mentioned sandbox is no more language specific. Threads & garbage collection are coming soon to WASM, which should open up most relevant languages in use today to this more efficient sandbox
- zapita 8y agoI agree, wasm is a notable step forward. But it's not magical either. For example you still need to expose system functionality to the application. That means either exposing existing OS APIs (which gives you compatibility at the cost of security and speed); or defining new APIs which take advantage of the properties of wasm (better security and speed; worse compatibility). As far as I can tell, the wasm community is still primarily focused on running in the browser. There is an explicit goal of supporting "non-web" targets, but no consensus on how to expose system APIs, let alone a full implementation.
- ori_b 8y ago> With the advent of WASM, the mentioned sandbox is no more language specific. Which removes many of the advantages.
- MrEldritch 8y agoHow do you figure?
- skybrian 8y agoOne issue might be that Cloudflare won't have the source and can't recompile the code. But perhaps web assembly is easy enough to decompile?
- vnorilo 8y agowasm doesn't as of now have any means of code generation independent from the JS api. There is also no way to obfuscate call targets or corrupt heap outside the module's linear memory. Any sandbox breaking bugs that do not involve JS would be codegen errors, AFAICT; in that case what you need to analyze is just the wasm blob and its interaction with the codegen pipeline.
- icebraining 8y agoArguably it's still language-specific: the difference is that the language is now WASM bytecode instead of JavaScript. You could already compile from other languages to JS.