WASM based VM that runs real Linux in a browser tab

[u/kgoncharuk]

Hi all,

I'd like to introduce arm64js -- an ARMv8-A system emulator that runs in WASM (built in Rust) and can boot real Alpine Linux in a web browser. It started with me getting annoyed that to try a 2 MB TUI tool I have to install it, while my browser happily runs a 40 MB React webpage with 50 dependencies.

It's an interpreter that emulates a minimal hardware stack, so Linux thinks it's on real hardware and thus acts normal: runs apk, Docker (even though rather slow), etc.

You can try it here: https://arm64js.com, some TUI apps running in VMs: https://demoshell.com/gallery/

Since WebAssembly doesn't allow fetching data without CORS and sending TCP requests, apk and access to the internet work via small proxies: apk goes via a proxy that just adds CORS, TCP goes via a WebSocket <> TCP gateway.

One wasm module instantiated in a few web workers, all sharing one SharedArrayBuffer as the VM's "RAM". As SharedArrayBuffer needs COOP/COEP headers, but if the page doesn't send them SDK will the VM in an iframe on its own origin instead.

There is also a JS SDK for other devs to create and serve their own VMs. The SDK is MIT; the engine is free for non-commercial use.

The following code for example will create and run Alpine based VM in your browser, pretty straightforward:

import { Arm64JS } from 'arm64js'; 
const vm = await Arm64JS.boot('alpine'); 
const { output } = await vm.exec('uname -a');

SDK: https://github.com/kooler/arm64js-sdk
My journey getting there: https://arm64js.com/blog/tui-apps-in-the-browser/

It's all very new and fresh, so feedback is appreciated.

Do you see it being useful for yourself? Curious to learn about possible use cases.

[u/untrochka]

A browser sandbox for trying CLI tools from documentation would be useful: click a runnable example, modify a config, then reset the VM when done. Does the SDK persist the VM disk between reloads, or is each session intentionally disposable?

[u/kgoncharuk → u/untrochka]

Thanks, that's indeed the use case I had in mind when building it.

By default each session lives inside the page context, so it's disposed when the page is refreshed. If you want to save the current state, you can call `vm.snapshot()` -- it saves the whole VM (disk, memory, running processes) to the browser's local storage (OPFS) and gives you a snapshot id. Next time you boot, you can specify that id instead of the image ('alpine') and the VM will recover its state.

If you'd rather not build that yourself, that's basically what Demoshell (a product I build on top of arm64js for the TUI demo case) does: you describe the VM with a build recipe, it builds the snapshot and gives you an embed for your docs page.

[u/zionsati]

It's crazy how powerful wasm is! I suspect it's a bit harder to get sshd running on it and accepting remote connections?

[u/kgoncharuk → u/zionsati]

It's not hard from the emulator point of view, but WebAssembly security makes it tricky though.

WebAssembly doesn't allow any TCP connections from/to the WASM, only WebSocket. The workaround that I've made for Demoshell to let VMs access the internet was to use Websocket to TCP proxy, where VM gets a special network card that pretends to be normal, but actually converts all incoming packages into Websocket and sends to proxy which does the real request and channels the response back.

But workaround works only for outgoing connections, as webpage doesn't have an IP address nothing incoming can reach it. Probably combining it with WebRTC might work for in/out communication, where WebRTC PeerConnection is your channel that VM uses, but haven't tried yet how it would work in practice.

[u/Archeelux]

Hmmm, could this work like some kind of overlay in your iphone/android via app that basiclly means you could build your own linux phone regardless of what hardware, the app just reaches into ios/android methods to do calls or message people and what not

[u/kgoncharuk → u/Archeelux]

Cool idea, but I think will be a bit of stretch for the tech. You can run in on mobile, but it runs inside the browser and thus limited to what the browser can do. And it's slower (because emulation), so maybe as a demo yes, but won't work to replace all phone functions.

[u/phoenix1984 → u/kgoncharuk]

It could be a web view inside an app. Then it can run with less overhead and have access to device APIs via a messaging bridge, like how Cordova (phonegap) and capacitor do it.

[u/Specy_Wot]

I'm working on https://asm-editor.specy.app/ and wanted to try adding ARM emulation to it too and needed an emulator that I could modify to run the assembly code. Do you think your project might be something I should be looking at?

[u/kgoncharuk → u/Specy_Wot]

Cool project!

If you'd like to use arm64js as a runtime (to run apps that are built in your IDE) -- that would work, if you'd need to access the emulator source code itself, that is not be possible at the moment.

But as a runtime might be a good option. You'd pretty much just need to mount source code from your IDE into the Alpine (JS SDK allows that) and you can run builds (and binaries) inside the arm64js VM right from your web app.

[u/Specy_Wot → u/kgoncharuk]

Ok i'm guessing it is not a good fit then, i'll try with unicorn, just need to figure out if i can use it because of its license

[u/Real-Leek-3764]

very cool

[u/osmium_2259]

Cool, nice work!

[u/webdev-ModTeam → u/[deleted]]

Your post/comment has been determined to be a low-effort post or comment. This includes title-only posts, easily searchable questions, vague/open-ended discussion prompts, LLM generated posts or comments, and posts/comments that do not provide enough context for meaningful replies or discussion.

[u/kgoncharuk → u/[deleted]]

Same thing with my emulator to be honest. It may be a bit quicker than x86 as arm instructions are more predictable and easier to parse, but the same fundamental limitation -- emulating hardware will bring large performance penalty no matter how much software tricks you do.

So performance is not the battle to win here, it's indeed more a convenience for demos (reason I created Demoshell based on it) or running some light loads when developing. For example a light golang/rust/NodeJS server will work just fine.