ARM64JS

Why

There is no good way to test server (or TUI) software without installing it despite most of it is lightweight enough to run (at least a demo) in a web browser. The initial idea came from frustration with TUI apps, majority of which are lighter than a standard React website yet you need to install them to see if there is a spark.

What is ARM64js

ARM64js is a ARMv8A emulator that runs in a web browser via Web Assembly. It emulates minimal hardware for the virtual CPU to run:

MMU with TLB
GICv3 (a shared distributor plus one re-distributor per vCPU)
Generic timer
PSCI (used to wake up a worker)
UART
RTC (wall-clock date and time)
virtio devices and PCIe host bridge
pmem / DAX region

vCPU itself comes with a user and a kernel privilege level, vector maths, new atomic and AES / SHA / CRC instructions. In web browser each vCPU runs in a separate worker. Up to 4 vCPUs are supported but in this case more is not always better. Communication between vCPUs in web browser is expensive, thus more vCPUs would improve performance only if running multithreaded software that does a lot of waiting. Single app would run faster on one vCPU.

Docker and docker compose are supported but might be slow.

How it works

VM powered by arm64js runs Alpine Linux on musl with optimised (patched) apk and some kernel tweaks to make it play nicely in web assembly based setup.

Network

APK

It is not possible to do http(s) requests without CORS from the webpage, meaning apk cannot work out of the box. To overcome this it goes via the proxy (apk.arm64js.com) which pretends to be an apk mirror while actually just proxies requests to dl-cdn.alpinelinux.org adding CORS headers.

Internet

A browser tab cannot send TCP requests, so when guest Linux needs to send TCP to anything on the internet, something outside the browser has to provide the real sockets. That's what the relay does:

the guest kernel takes care of TCP/IP work — checksums, retransmits, windows — and hands ethernet frames to the virtual device
net worker receives those frames and send them over the WebSocket to the relay
relay opens real socket and proxies the data

Relay cannot read HTTPS. TLS is done by the guest and terminated at the real server. The relay only sees encrypted bytes going by but not the data itself.

Note: using relay requires demoshell.com account to avoid it being used as an anonymous proxy and to be able to limit the traffic.

Snapshots

At any point of the lifecycle the VM can be snapshotted, which means it's possible to do a setup (install software, change linux config, etc) and then snapshot the result. Snapshot includes:

Guest RAM
CPU state
Device state
Metadata (snapshot related)

Loading from the snapshot is pretty quick, assuming that the size of the VM hasn't increased much, snapshot will load as quickly as the original guest OS (which is technically also a snapshot).