crosvm

crosvm is a hosted (type-2) virtual machine monitor (VMM) designed to run untrusted operating systems in a sandboxed environment. It is similar to QEMU-KVM or VirtualBox but prioritizes safety through the use of the Rust programming language and a multi-layered security architecture.

Security Model

• Runtime Sandboxing: Each virtual device (such as disk or network) is executed inside a minijail sandbox by default, isolating it from other devices.
• Syscall Security: crosvm utilizes a seccomp syscall security policy to prevent unauthorized system calls if a device is compromised.
• Isolation: The sandbox architecture is designed to prevent attackers from escaping the virtual environment to perform harmful actions on the host operating system.

Supported Architectures

• x86_64
• aarch64
• riscv64

Supported Hypervisors

• Linux/Android: KVM, Gunyah (Qualcomm), GenieZone (MediaTek), Halla (Exynos).
• Windows: WHPX (Windows Hypervisor Platform), HAXM (Intel).

Virtio Device Support

crosvm implements various paravirtualized devices via the virtio standard:

• Network: virtio-net (supports vhost and slirp backends).
• Storage: virtio-block (supports raw, qcow2, zstd, and Android sparse formats).
• Graphics: virtio-gpu (supports 2D/3D acceleration via virglrenderer, gfxstream, or vulkano).
• Display/Input: Integrated virtio gpu cross domain support for Wayland passthrough.
• Audio: virtio-snd (supports CRAS for ChromeOS, AAudio for Android, etc.).
• File System: virtio-fs and virtio-9p.
• Other: Console, RNG, Balloon, Vsock, TPM, Pmem, Video Decoder/Encoder.

The infra/recipes directory contains automation scripts (recipes) for various infrastructure tasks related to crosvm. These recipes are designed to be run via a recipe engine (likely Luci) and cover tasks such as:

• Image Building: build_baguette_image (builds Baguette rootfs) and uprev_baguette_image (uploads uprevs).
• Platform Builds: build_linux and build_windows.
• Documentation: build_docs (builds and uploads mdbook/API docs).
• Maintenance: health_check, presubmit, push_to_github, and update_chromeos_merges.
• Image Management: uprev_refvm_image (uploads uprevs of the refvm image).

Halla is a type-1 hypervisor specifically designed for Exynos proprietary ARM-based SoCs. It is designed to increase system security by trapping high-level exceptions and isolating memory access segments from various operating systems. This isolation helps prevent attacks originating from a compromised guest OS.

Key capabilities include:

• Support for multi-core Virtual Machines (VMs).
• Virtual interrupt injection.
• Ability to boot guest VMs with a Linux kernel to a shell.
• Implementation of Halla's irqchip.
• Automatic probing of the proper hypervisor backend using naive logic.

GenieZone is a type-1 hypervisor specifically designed for MTK proprietary ARM-based SoCs. It enhances system security by trapping high-level exceptions and isolating memory access segments from various operating systems, which helps prevent attacks originating from a compromised guest OS.

Current Capabilities:

• GenieZone hypervisor implementation
• GenieZone irqchip implementation
• GenieZone configuration and feature support
• Hypervisor backend probing via naive logic
• Virtual interrupt injection
• Booting guest VMs with a Linux kernel to a shell environment

Planned Features (Backlog):

• Integration with protected VM and pvmfw
• Multi-core VM support

The FFmpeg wrapper provides minimal bindings to FFmpeg 6.1+ for use with the virtio-video device. It allows running a virtual video device backed by software decoding or encoding. This is primarily used for development and testing when the host lacks supported hardware video acceleration.

Key characteristics:

• Minimal Dependencies: It only uses libavcodec, libavutil, and libswscale from the FFmpeg side.
• Custom Bindings: It uses custom bindings rather than external Rust crates to ensure compatibility with system FFmpeg and to comply with licensing requirements.
• Compatibility: Requires FFmpeg 6.1 or newer.

Crosvm CIPD packages are used by luci builders. You can view available package information at the following URL:

https://chrome-infra-packages.appspot.com/p/crosvm

crosvm supports various hypervisors depending on your operating system and architecture:

Linux

• KVM: The preferred hypervisor for Linux. It is tested upstream.
• Geniezone: Supported on aarch64 only. Used as a backend for the Android Virtualization Framework.
• Gunyah: Supported on aarch64 only. Used as a backend for the Android Virtualization Framework.
• Halla: Supported on aarch64 only. Used as a backend for the Android Virtualization Framework.

Windows

• WHPX: Windows Hypervisor Platform.
• HAXM: Intel Hardware Accelerated Execution Manager.

The audio_streams crate provides a foundational interface for audio playback in crosvm. It is designed to abstract audio subsystems, allowing playback to be routed to different backends such as Alsa or cras.

To begin implementing or testing audio logic without a specific backend, you can use the provided NoopStreamSource, which serves as an empty playback example.

vHost is a pure Rust library for implementing the vhost-user protocol. This protocol allows implementing vhost backend drivers in userspace, serving as a complement to the Linux kernel's ioctl interface.

Key concepts of the protocol:

• Purpose: Establishes virtqueue sharing with a userspace process on the same host.
• Communication: Uses Unix domain sockets to share file descriptors via ancillary data in messages.
• Roles:
  • Frontend: The application that shares its virtqueues.
  • Backend: The consumer of the virtqueues.
• Connection Modes: Both the frontend and backend can act as either a client (connecting to a socket) or a server (listening on a socket).

Crosvm uses the cros_tracing crate as a frontend for trace points to debug and diagnose performance. It is extensible and supports multiple backends:

• noop: The default backend. All trace points are compiled out, resulting in no performance degradation.
• trace_marker: An ftrace backend that logs events to the Linux kernel. This is only supported on Linux systems and must be enabled at compile-time using the --features trace_marker flag.

Trace events are compiled into the binary, so changes to trace points or categories require recompiling crosvm.