14 ms·

The tradeoff is only some performance, there is no security risk. CheerpX used standard WebAssembly/JavaScript/HTML5, there is truly no difference between this

The tradeoff is only some performance, there is no security risk. CheerpX used standard WebAssembly/JavaScript/HTML5, there is truly no difference between this and any other Web page you might visit. The scrolling behavior you mentioned is actually a feature, we want to give people time to read the first message before filling up the console.

pbronez 6y ago
Hi Alessandro - amazing work on this & thanks for the reply. This is the coolest WASM demo I've seen since the first Emscripten release. Moving WASM execution from a compile-time choice to a runtime choice is pretty amazing. I need to noodle on the implications of the portability benefits. > The tradeoff is only some performance, there is no security risk. CheerpX used standard WebAssembly/JavaScript/HTML5, there is truly no difference between this and any other Web page you might visit. I understand that the security model is more like a webpage than a local binary. What I don't understand is: (1) what is the relative difficulty of escaping a full, local VM vs a local browser sandbox vs microVM container? That is, if you want to run an untrusted x86 binary locally, is CheerpX + browser sandbox really as safe as VirtualBox or firecracker? I suspect there's a speed/security tradeoff happening somewhere. (2) how complete is the set of operating system APIs available to an x86 running in WASM via CheerpX vs running that same application locally? That is, what local functionality might I sacrifice to use the browser? (3) what is the nature and magnitude of the performance hit? Obviously you have to load the binary over the network in this demo, but locally-hosted resources should be fine.
- apignotti 6y ago
  (1) I am not sure I understand the question. It seems to me that it really boils down to "Do you trust the browser to run arbitrary code?" There is truly no way for CheerpX to do anything more than what your average Web page could do. (2) We are implementing syscalls and devices as they are needed for the various use cases we are considering. In general even if something is not natively supported in the browser it can still be virtualized to various degrees. In particular CheerpX provides a virtualized FileSystem that does not map to your local files. The same would apply for the virtual disks in traditional VMs though. (3) We plan to release benchmarks soon, but the level of performance is very promising. Consider that we have been using the Flash plugin as our main benchmark which is very demanding. For the REPL use case the limiting factor right now is I/O performance, but we are already working on this and we thing we will achieve much better results very soon. In general, all aspects of CheerpX performance will improve, we are really not done yet.

pbronez 6y ago

Hi Alessandro - amazing work on this & thanks for the reply. This is the coolest WASM demo I've seen since the first Emscripten release. Moving WASM execution from a compile-time choice to a runtime choice is pretty amazing. I need to noodle on the implications of the portability benefits. > The tradeoff is only some performance, there is no security risk. CheerpX used standard WebAssembly/JavaScript/HTML5, there is truly no difference between this and any other Web page you might visit. I understand that the security model is more like a webpage than a local binary. What I don't understand is: (1) what is the relative difficulty of escaping a full, local VM vs a local browser sandbox vs microVM container? That is, if you want to run an untrusted x86 binary locally, is CheerpX + browser sandbox really as safe as VirtualBox or firecracker? I suspect there's a speed/security tradeoff happening somewhere. (2) how complete is the set of operating system APIs available to an x86 running in WASM via CheerpX vs running that same application locally? That is, what local functionality might I sacrifice to use the browser? (3) what is the nature and magnitude of the performance hit? Obviously you have to load the binary over the network in this demo, but locally-hosted resources should be fine.

apignotti 6y ago
(1) I am not sure I understand the question. It seems to me that it really boils down to "Do you trust the browser to run arbitrary code?" There is truly no way for CheerpX to do anything more than what your average Web page could do. (2) We are implementing syscalls and devices as they are needed for the various use cases we are considering. In general even if something is not natively supported in the browser it can still be virtualized to various degrees. In particular CheerpX provides a virtualized FileSystem that does not map to your local files. The same would apply for the virtual disks in traditional VMs though. (3) We plan to release benchmarks soon, but the level of performance is very promising. Consider that we have been using the Flash plugin as our main benchmark which is very demanding. For the REPL use case the limiting factor right now is I/O performance, but we are already working on this and we thing we will achieve much better results very soon. In general, all aspects of CheerpX performance will improve, we are really not done yet.