crosvm: A Rust VMM for Sandboxed Virtual Devices

Why crosvm exists for isolated guest workloads

crosvm addresses the need to run Linux or Android guests inside controlled environments. Its original purpose was ChromeOS virtualization for Linux through Crostini and Android guests through ARCVM. The README also identifies use in Android's TerminalApp, Android Cuttlefish, and Windows. That makes crosvm a component for platforms and products that need controlled guest execution rather than a general-purpose consumer virtualization application.

The design centers on isolation of untrusted guest code. crosvm uses hardware-assisted virtualization and implements a range of virtual devices through the virtio standard. Its security model is more specific than simply placing a guest in a virtual machine: virtual devices can run in separate processes, and those processes can be jailed with Linux namespaces, seccomp filters, capabilities restrictions, and Minijail. This process-per-device arrangement gives platform integrators a mechanism for reducing the system access available to an individual device.

The target audience is developers integrating virtualization into ChromeOS, Android, Windows, or similar systems. It is also relevant to engineers who need Rust VMM internals, architecture-specific guest support, or device backends that can be separated into isolated processes. The repository is a GitHub mirror of the authoritative Chromium source tree, so contribution workflow and development authority are centered on Chromium Gerrit rather than ordinary GitHub pull requests.

crosvm's process-per-device security model

The documented architecture has a main process that initializes the virtual machine and coordinates its operation. A virtual device can then be forked into its own device process. This differs from a model in which every device necessarily remains inside one large host process. The separate process becomes the boundary at which system access can be restricted.

The README describes Minijail as the jail layer. VFS isolation can use `pivot_root`, while PID, user, and network namespaces provide separate kernel-level views. A BPF-based seccomp filter restricts system calls to those required by the specific device. Unnecessary Linux capabilities are dropped. The documented ordering is therefore process separation followed by a restricted runtime environment. That arrangement is intended to limit what happens if a device implementation is compromised.

The repository layout reinforces that this is a broad VMM rather than one executable with a small feature surface. Directories include `hypervisor`, `devices`, `disk`, `jail`, `kernel_loader`, `kvm_sys`, `gpu_display`, `audio_util`, `cros_async`, `crosvm_cli`, and `crosvm_control`. The crate uses the `crosvm` package name and exposes a default binary named `crosvm` from `src/main.rs`. The README also points to `ARCHITECTURE.md` for the internal design and communication framework.

Supported CPU and hypervisor paths

crosvm documents guest CPU architecture support for `x86_64`, `aarch64`, and `riscv64`. The host and virtualization path is platform-dependent. On Linux and Android, the listed hypervisor backends are KVM, Qualcomm Gunyah, MediaTek GenieZone, and Exynos Halla. On Windows, the listed backends are WHPX and Intel HAXM.

This split matters when evaluating adoption. KVM is listed for Linux and Android, but the presence of a guest architecture does not by itself establish that every combination of host platform, hypervisor, guest image, and device backend is available. The README does not provide a compatibility matrix with versions, and it does not document a single universal setup command for all backends. An engineer would need to consult the user guide and the platform-specific code before selecting a configuration.

The VMM also uses several performance-oriented interfaces and features, including `io_uring`, vhost, and the internal `cros_async` runtime. Those names identify implementation mechanisms, not a promise that every deployment will produce the same result. No benchmark results or workload measurements are supplied in the README.

Virtio devices and backend-dependent functionality

The device layer is broad, but several capabilities depend on an external backend or host integration. Networking includes `virtio-net` with optional vhost and slirp backends. Storage supports `virtio-block` for raw, qcow2, zstd, and Android sparse formats. Graphics use `virtio-gpu` with 2D and 3D acceleration through `virglrenderer`, `gfxstream`, or `vulkano`. Display and input can use integrated virtio GPU cross-domain support for Wayland passthrough.

Audio provides `virtio-snd`, with CRAS for ChromeOS and AAudio for Android among the listed backends. Filesystem devices include `virtio-fs` and `virtio-9p`. The README also lists console, RNG, balloon, vsock, TPM, pmem, and video decoder or encoder devices. This breadth makes crosvm relevant to full guest environments, but it also creates a dependency matrix. A product that only needs a console and block device does not automatically need every graphics or audio backend, while a product requiring `virtio-fs` must verify the host-side support relevant to its deployment.

The documentation is clear about the names of these capabilities, but it does not state that all backends are built or enabled in every configuration. Backend availability should therefore be checked in the user guide, build configuration, and target environment rather than inferred from the feature list.

Building crosvm through its development container

The README identifies a modern Linux kernel with KVM access and either Podman or Docker as prerequisites. It recommends the provided development container for building and development rather than documenting a standalone package installation procedure. The repository is licensed under BSD-3-Clause, and the README links to the user guide for usage details.

The documented build command is below. It invokes the repository's development-container helper and then the release build script. The command should be run from the repository root, where `tools/dev_container` and `tools/build_release` are available.

./tools/dev_container ./tools/build_release

After the build completes, the README directs users to an external example-usage page for running a simple Linux guest. The README does not include that guest's command-line invocation, so no additional flags or configuration are presented here. The repository's `Cargo.toml` identifies the package as `crosvm`, uses Rust edition 2021, and defines the `crosvm` binary, but it does not replace the documented container workflow with a shorter installation command.

The Python tooling is limited to development configuration in the `pyproject.toml`. It configures Black with a 100-character line length and Pyright in strict mode for `tools`, while excluding `infra` and certain Windows or contribution tools. This is relevant to contributors, but it is not a runtime prerequisite for launching a guest.

Operational limits and maintenance costs

The main limitation is platform variability. crosvm can use different hypervisor backends across Linux, Android, and Windows, and its graphics and audio support also depends on named backends. A successful build in the development container does not by itself prove that a deployment has KVM access, the required host kernel, the selected backend libraries, or the permissions needed for the guest devices. The README gives no universal compatibility matrix and no performance measurements.

Another practical constraint is that the GitHub repository is read-only and is described as a mirror. Contributions go to Chromium Gerrit, and the authoritative source is the Chromium repository. The project has no GitHub releases, so release packaging and upgrade conventions cannot be inferred from that repository. The README does not document rollback, release tags, migration steps, or a stable version promise.

The repository's last push was on 2026-10-15. That is a recent maintenance signal based on repository activity, but it is not a release schedule. Upgrades may involve Chromium source changes rather than a GitHub release artifact. Users should inspect the target branch and Chromium documentation before selecting a revision. BSD-3-Clause governs licensing, but this article does not interpret the license or provide legal guidance.

crosvm compared with a kernel-module desktop hypervisor

crosvm and a conventional desktop virtualization stack approach isolation differently. A desktop-oriented hypervisor commonly exposes a general-purpose virtualization interface to one host installation, with host configuration managed as part of that system. crosvm is designed as a component that can split individual virtio devices into sandboxed processes and can be integrated into a larger product such as ChromeOS or Android TerminalApp.

The distinction is architectural, not a claim that one approach is always better. crosvm's process-per-device model and Minijail integration are directly documented, while its platform support spans multiple hypervisor backends. That fits product teams that need explicit control over device boundaries and Rust implementation details. A user who only wants to install a familiar desktop virtualization manager is unlikely to need this component-level VMM and its build dependencies.

crosvm also does not present itself as a simple substitute for a guest operating system or a complete virtual desktop. It starts and coordinates a guest environment, but the guest image, disk format, kernel, device configuration, and host integration remain deployment concerns. The decision depends on whether the product needs a VMM it can embed and constrain, rather than merely a convenient way to run one VM.

Editorial conclusion

Choose crosvm when a product needs a Rust-based VMM with explicit device isolation and virtio support across several guest architectures. Do not select it as a general-purpose desktop hypervisor without first checking platform, hypervisor, graphics, audio, and sandbox dependencies. The first verification should be whether the documented development container builds on the target system, followed by a Linux guest run using the linked example. The repository's last push was on 2026-10-15, but there is no GitHub release history to use as a version or upgrade baseline.

Frequently asked questions

Official sources

1. google/crosvm on GitHub
2. Issues
3. License: BSD-3-Clause
4. Project website
5. README