Hacker News Reader

Comment by pbronez | Hacker News Reader

Pretty cool!

What are the tradeoffs of running virtualized x86 in the browser via WASM relative to a traditional VM (e.g. Virtual Box) or VM-like container runtime like Firecracker [0]? I would expect to get improved portability (it's a webpage) at the cost of some performance and security.

The ShowHN link is for the REPL demo, the actual homepage for the CheerpX x86 to WASM virtualizer is here [1]

Minor bug: when you load a new REPL, the loading log fills the screen and continues below the fold without auto-scolling to keep up with new output. You have to manually scroll past a list of all the component modules to see the new REPL.

[0] https://firecracker-microvm.github.io/

[1] https://leaningtech.com/pages/cheerpx.html

View on HN

Not the Author, but I can hazard a few guesses...

Running this in the browser makes for a ridiculously easy setup. You can get up and running very quickly by just giving someone a URL (probably with a pre-unpacked image). Setting up a VM on the other hand, can be daunting if you don't already have the infrastructure setup. This might be a benefit of running this WASM VM vs a local VM.

Second, you get the security benefit of running the code on your local computer as opposed to a remote VM. This may not be a big issue, but for some circumstances, it could be.

Third, by running it locally as opposed to on a remote VM, might be more interactive, in that you don't have the round-trip time client -> server -> client. But this depends on how performant the WASM VM is.

This isn't something you do for performance. The WASM VM seems "fast enough", but this isn't something that will be faster than many cloud-based VMs. For me, the major benefits would be setup/maintenance and security.

Personally find this to be a pretty cool project, but I'm not sure of where I'd use it outside of teaching... but it's quite impressive.

For the scrolling -- I found that once I scrolled to the bottom once, it auto-scrolled. But I was confused when I unpacked Python by this too.

> Running this in the browser makes for a ridiculously easy setup. You can get up and running very quickly by just giving someone a URL (probably with a pre-unpacked image)... I'm not sure of where I'd use it outside of teaching... but it's quite impressive.

Teaching seems like a great use case. Maybe they'll use similar licensing as their Cheerp compiler [0] and provide a basic community tier. You could give students a foolproof (?) way to run a controlled set of applications locally without the confusion of setting up a local VM host or the expense of hosting virtual machines for the class. That assumes your students have decent computers.

Actually, this would be a nice way to sideload real applications onto Chromebooks. Certainly more secure/accessible/maintainable than unlocking all the default protections and side-loading Linux first.

[0] https://leaningtech.com/pages/cheerp.html

The company has already donated their technology and time to emulating educational Java apps under WASM, which is helpful for school districts that are Chromebook-only.

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.

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.

(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.

Virtualized x86 in the browser doesn't get anywhere near the performance of a traditional VM that is doing kernel-level virtualization. Also, your VM images will be huge for most software packages that do anything useful.

The upside is obvious, it's idiot-proof and zero setup.

Any thoughts on a simple way to benchmark that? I suppose it'd be easy enough to time some python scripts in the hosted REPL against local execution....

Reply on news.ycombinator.com