41–50 of 111 posts
Nice work. I love simple and "conservative brute force" techniques like this--brute force in that you run all the example call sites in the interpreter, conservative in that it bails out when things get hard (e.g. bail out if a single basic block is executed too many times). I am wondering if this technique could be hybridized with abstract interpretation or partial evaluation, which are known techniques in compilers…
On the second part, I have to do some thinking and coming back, thanks!
Earlier quoted context omitted.
This sounds like ActiveX. Security issues related to ActiveX are solved or not? Because if they are not, then it's just a reskin of ActiveX and malware authors gonna have a field day.
That is the thing with fake security advertising of WebAssembly. You can just as easily compile heartbleed into WebAssembly and call it a day. Yes it is sandboxed, but hardly any different than running an OS process with sandboxing lock down regarding which OS syscalls are allowed. Think it this way, just because an OS container cannot exploit its host (minus hypervisor bugs), that doesn't mean that what is inside is…
The syscall surface is zero by default. WASI of course expands that by a lot, but sane WASI implementations require restrictive whitelisting of available resources like specific files or directories that can be accessed. (wasmtime-wasi does this well,for example). The whole wasi spec is aiming for capability based security, including things like only providing access to pre-opened sockets.
All production deployments of server side Wasm I have seen have very tight scoping.
Sandboxing on Linux, in contrast, is a complicated mess, with a myriad of partial and leaky solutions (SELinux, Apparmor, Docker, Snap, Flatpak, ...) .
Having a good cross platform toolkit is completely out of reach.
The only OS that has comparable sandboxing that is practical is Fuchsia.
Earlier quoted context omitted.
WebAssembly implies static linking (malloc / printf & all are part of the shipped module) and code size matters since it directly influence users (since there might be delays in downloading big payloads). Both factors plays a role in deciding to plan putting work in optimizations like this. There are some general gains to be had with this optimization, and probably the same ideas were already around for a while, but…
Not necessarily, shared libraries are on the WebAssembly roadmap.
Earlier quoted context omitted.
That is the thing with fake security advertising of WebAssembly. You can just as easily compile heartbleed into WebAssembly and call it a day. Yes it is sandboxed, but hardly any different than running an OS process with sandboxing lock down regarding which OS syscalls are allowed. Think it this way, just because an OS container cannot exploit its host (minus hypervisor bugs), that doesn't mean that what is inside is…
You keep repeating this, but it's simply not true. The syscall surface is zero by default. WASI of course expands that by a lot, but sane WASI implementations require restrictive whitelisting of available resources like specific files or directories that can be accessed. (wasmtime-wasi does this well,for example). The whole wasi spec is aiming for capability based security, including things like only providing access…
There is no magic in WASM, only when the only thing it does is warming up a CPU.
Optimizations like this are incredible to me. In my compiler class in college, I was smitten by how different optimizations were performed, and we only ever worked with pretty basic constant propagation and dead code elimination. The work here is incredible. My respect to the entire team.
Same!
This company has an x86-to-WASM compiler that lets you execute arbitrary binaries in the browser. Also a JVM to WASM transpiler. There's a fantastic Meetup presentation given by one of them where they show running a C++ multiplayer game with both client AND server running in a browser, using WebRTC as a networking polyfill. Really mindblowing: https://youtu.be/7JUs4c99-mo?t=167
> running a C++ multiplayer game with both client AND server running in a browser, using WebRTC as a networking polyfill Ok, now you have my attention. Been waiting for that possibility for a while!
This company has an x86-to-WASM compiler that lets you execute arbitrary binaries in the browser. Also a JVM to WASM transpiler. There's a fantastic Meetup presentation given by one of them where they show running a C++ multiplayer game with both client AND server running in a browser, using WebRTC as a networking polyfill. Really mindblowing: https://youtu.be/7JUs4c99-mo?t=167
What would the impact be on battery life compared to native execution? Can one get it just as power efficient as native execution, only slower? For computationally less intensive applications browser portability might be an excellent tradeoff. It gives a new meaning to the slogan "write once, run everywhere".
This company has an x86-to-WASM compiler that lets you execute arbitrary binaries in the browser. Also a JVM to WASM transpiler. There's a fantastic Meetup presentation given by one of them where they show running a C++ multiplayer game with both client AND server running in a browser, using WebRTC as a networking polyfill. Really mindblowing: https://youtu.be/7JUs4c99-mo?t=167
At what point does the browser become an "os", what's next? Chrome hypervisor?
When it no longer requires an OS to run.
Earlier quoted context omitted.
You keep repeating this, but it's simply not true. The syscall surface is zero by default. WASI of course expands that by a lot, but sane WASI implementations require restrictive whitelisting of available resources like specific files or directories that can be accessed. (wasmtime-wasi does this well,for example). The whole wasi spec is aiming for capability based security, including things like only providing access…
And will keep repeating ad eternum given the fake security sales from Webassembly, for God's sake evem the standard has a security section mentioning possible issues not addressed. There is no magic in WASM, only when the only thing it does is warming up a CPU.