Google Deploys Rust VM to Shield Chrome OS From Untrusted Linux Code

Chrome for Developers

Hardware-isolated hypervisors and sandboxed system jails eliminate the need for secondary laptops by preventing containerized development exploits from accessing host personal data, networks, or physical peripherals.

AI-assisted summary of Linux for Chromebooks: Secure Development (Google I/O ’19) — original source. Check the original for full context.

Source published: 2019-05-09

Key ideas

• Chrome OS has scaled Linux support (Crostini) to over 50% of the active Chromebook fleet, running directly on 8th-generation Intel Core hardware without requiring dual-booting or standalone desktop shells. (2:46)
• The platform enforces strict security boundaries by executing untrusted developer tools inside LXD containers nested within a Google-signed, read-only VM managed by crosvm—a memory-safe hypervisor written in Rust. (5:30)
• File sharing and USB device passthrough rely on heavily jailed, Rust-implemented services and explicit user authorization, ensuring guest environments cannot inspect host files or harvest peripheral identifiers. (11:21)
• Local web development operates over automated VSOCK tunneling between daemons, enabling zero-config localhost routing and desktop PWA testing while isolating container network namespaces from host traffic. (15:46)

Detailed notes

## Background Published by Chrome for Developers on YouTube on May 9, 2019, this presentation from Google I/O 2019 features Dylan Reid, Tom Buckley, and Sudha Broslawsky introducing Linux for Chromebooks (codenamed Crostini). The session explores the underlying architecture and user-experience design decisions that provide developers with a secure, sandboxed Linux development environment on Chrome OS.

## TL;DR The speakers present Crostini as a solution to the common developer dilemma of balancing risky development scripts with sensitive personal data on a single machine. They break down the security architecture—anchored by Rust, the custom `crosvm` hypervisor, jailed device emulators, and LXD containers—which isolates untrusted code while keeping the host Chrome OS environment protected. Through live demonstrations, the team showcases seamless file sharing, automated local web server forwarding over VSOCK, and granular USB peripheral passthrough for Android debugging. Advanced developer features are also highlighted, including direct access to the Termina VM via Crosh, btrfs copy-on-write snapshots, and multi-distribution support like Arch Linux.

## Atmosphere & style The presentation carries the polished, collaborative energy characteristic of Google I/O, seamlessly alternating between high-level product design, deep virtualization engineering, and live desktop demos. The speakers share an easy, relatable rapport, opening with empathetic humor about bad development habits like piping untrusted scripts into sudo before diving into rigorous technical breakdowns. Watching the session feels reassuring and practical, as complex sandboxing concepts and hypervisor pipelines are translated into smooth, everyday developer interactions that eliminate the anxiety of system compromise.

## Bulletin - [02:46](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=166s) Chrome OS has scaled Linux support (Crostini) to over 50% of the active Chromebook fleet, running directly on 8th-generation Intel Core hardware without requiring dual-booting or standalone desktop shells. - [05:30](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=330s) The platform enforces strict security boundaries by executing untrusted developer tools inside LXD containers nested within a Google-signed, read-only VM managed by crosvm—a memory-safe hypervisor written in Rust. - [11:21](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=681s) File sharing and USB device passthrough rely on heavily jailed, Rust-implemented services and explicit user authorization, ensuring guest environments cannot inspect host files or harvest peripheral identifiers. - [15:46](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=946s) Local web development operates over automated VSOCK tunneling between daemons, enabling zero-config localhost routing and desktop PWA testing while isolating container network namespaces from host traffic.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=0s) Developers frequently compromise their machine's security under deadline pressure, running unverified scripts that jeopardize personal data on primary work devices. - [02:46](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=166s) Crostini integrates standard Debian terminal utilities and graphical Linux applications seamlessly alongside native Chrome OS and Android apps. - [05:30](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=330s) The crosvm hypervisor is built in Rust to eliminate critical memory safety vulnerabilities such as buffer overflows and use-after-free conditions. - [05:30](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=330s) Virtual device emulators within crosvm, such as the display driver and RNG, operate in sandboxed, least-privilege pillars with no network access. - [09:40](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=580s) Crostini's core design philosophy prioritizes developer intuition, native desktop integration, and technical simplicity that keeps hypervisor complexity hidden. - [11:21](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=681s) Host file sharing is mediated by '9s', a custom, fuzzed 9P file server written in Rust that restricts guest visibility strictly to explicitly shared directories. - [14:10](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=850s) The Chrome OS Files app provides default access to a dedicated 'Linux Files' directory while allowing two-click sharing of local and Google Drive folders. - [15:46](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=946s) Development web servers run inside nested network namespaces and are bridged to Chrome OS host browsers via automated VSOCK port forwarding. - [19:10](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=1150s) Localhost endpoints mapped from Crostini containers are treated as secure contexts, enabling full support for PWA desktop installation workflows. - [20:30](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=1230s) USB peripheral access presents a major security risk for machine fingerprinting and firmware exploits, requiring emulated empty buses until users grant permission. - [24:02](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=1442s) Physical Android hardware debugging is managed via granular system notification prompts that can be revoked at any time in Chrome OS Settings. - [25:54](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=1554s) Advanced users can access the underlying Termina VM via the Crosh shell and manage containers directly using LXD command-line tooling. - [28:53](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=1733s) Because Crostini uses the btrfs filesystem inside the VM, developers can leverage copy-on-write container snapshots for risk-free system experimentation. - [28:53](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=1733s) The platform supports launching non-Debian distributions, such as Arch Linux, directly from Canonical's public image repositories inside Termina. - [32:28](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=1948s) Upcoming Crostini roadmap items include native UI support for multi-container workflows and integrated backup and restore mechanisms.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=0s) Developer Workflows and the Two-Laptop Dilemma

At the end of day two at Google I/O 2019, Sudha Broslawsky (Designer on Crostini), Dylan Reid (Chrome OS Virtualization Lead), and Tom Buckley (Product Manager for Linux on Chromebooks) take the stage to introduce Linux for Chromebooks, codenamed Crostini. Rather than pitching new development frameworks or target platforms, Tom emphasizes that their session focuses squarely on developer peace of mind, achieved by carefully balancing simplicity and security.

Sudha conducts an informal show of hands across the packed room, noting that 100% of the audience members are developers who also rely on their primary machines for sensitive personal tasks such as filing taxes and checking personal email. When she asks how many are genuinely worried about security, virtually the entire room keeps their hands raised.

Addressing this anxiety, Dylan describes the all-too-relatable cycle of hitting an engineering roadblock on a new project under tight deadlines. When searching online for a quick fix, developers frequently stumble across suspicious instructions—such as piping an unverified script from an untrusted site directly into `sudo`. While knowing it violates every security principle, the pressure of a looming deadline often wins out: “And then it happens again and again, and eventually, I end up with a system that I don't trust as much as I should, because I don't really know what code I've run on it anymore.” To cope with this reality, Dylan explains that his personal workaround had long been carrying two distinct laptops—one dedicated solely to risky development work and another strictly reserved for personal and secure activities. Crostini, however, was designed to eliminate the need for that second laptop.

- 100% of developers surveyed in the room reported using their work machines for high-stakes personal business like taxes and email. - The habit of running unverified scripts via `curl | sudo` forces developers into an uncomfortable compromise between velocity and system trust.

---

[02:46](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=166s) Bringing Linux to Chrome OS: Setup and Integration

Tom Buckley explains that while Chrome OS was built from the ground up to be safe and frictionless, it originally prevented engineers from doing serious development because its locked-down environment could not execute standard developer tooling. That trade-off changed following the previous year's Google I/O announcement introducing Linux support. By mid-2019, Crostini expanded to support over 50% of the active Chromebook fleet, powering eighth-generation Intel CPU hardware such as the Lenovo Yoga Book C630 and the Acer Chromebook Spin 13.

Turning on Linux requires only a couple of clicks in settings. Beneath the surface, Chrome OS handles the complex tasks of downloading a virtual machine image, standing up container environments, and configuring all necessary bridging services. Once complete, a standard terminal icon appears directly in the Chrome OS launcher. The environment drops the user into a familiar Debian system pre-populated with standard utilities such as Git and Vim. Additional tools can be pulled in using the standard APT package manager or by installing downloaded `.deb` packages. Graphical applications integrate transparently, appearing alongside web and Android apps in the Chrome OS app launcher and managing windows directly through the native Chrome OS window manager without forcing users into a clunky secondary desktop environment.

```mermaid flowchart TD accTitle: Chrome OS Crostini User Experience Architecture accDescr: Diagram illustrating how Linux tools and applications integrate seamlessly into the native Chrome OS launcher and window manager.

subgraph ChromeOS ["Native Chrome OS Desktop"] Launcher["Chrome OS App Launcher"] WinMgr["Chrome OS Window Manager"] end

subgraph CrostiniLayer ["Linux (Crostini) Integration"] Term["Debian Terminal Environment\n(Git, Vim, APT)"] GUIApps["Graphical Linux Tools\n(IDEs, Editors,.deb packages)"] end

Term --> Launcher GUIApps --> Launcher GUIApps --> WinMgr ```

Tom underscores that convenience cannot come at the expense of safety: “You don't have to worry about malware accessing your files, snooping on your traffic, or infecting your peripherals.” Because developers need verifiable architectural guarantees rather than blind trust, the remainder of the talk dives into the exact virtualization primitives making this safety model possible.

- Linux support is available on more than half of Chromebooks, including high-end 8th-gen Intel Core devices like the Lenovo Yoga Book C630 and Acer Chromebook Spin 13. - Linux applications—both command-line tools and full graphical user interfaces—run seamlessly side-by-side with Chrome OS apps without requiring a standalone X11 or desktop shell session.

---

[05:30](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=330s) Crostini Architecture: Rust, crosvm, and Sandboxed Pillars

Dylan Reid returns to explain the security architecture under the hood. Chrome OS has traditionally relied on multi-layered defense-in-depth, isolating untrusted web code within sandboxed browser renderers with severely constrained system calls. However, traditional developer workflows require arbitrary Linux kernel privileges and unrestricted package installations that would compromise the host system if run natively.

To bridge this gap without endangering the host, Google introduced a hardware-isolated virtualization layer managed by `crosvm`, a custom virtual machine monitor written from scratch in Rust. Rust was selected specifically for its memory safety, eliminating entire classes of security bugs such as buffer overflows, use-after-free conditions, and integer overflows. Within this hypervisor runs a Google-signed, read-only guest VM kernel and root filesystem. Because the guest VM base image is cryptographically verified and immutable, users cannot permanently brick their boot environment.

To provide mutable developer freedom inside this read-only VM, Google partnered with Canonical's LXD team to host Debian system containers. Within these containers, developers have full root access to install any library, language, or tool. Furthermore, `crosvm` separates virtual device emulators into isolated, least-privilege sandboxes or "pillars": - The random number generator (RNG) process runs in an empty filesystem with zero network access. - The virtual display driver process handles UI rendering but is completely cut off from network access, ensuring it cannot exfiltrate host data even if compromised.

```mermaid flowchart TD accTitle: Crostini Security and Isolation Architecture accDescr: Layered Crostini architecture showing the separation between Chrome OS host, crosvm sandboxes, the guest VM, and the Debian container.

subgraph Host ["Chrome OS Host Layer"] HostOS["Chrome OS Base System\n(Browser, Personal Data, Taxes, Banking)"]

subgraph CrosvmPillars ["crosvm (Rust VMM Sandboxes)"] RNG["RNG Device Jail\n(Empty FS, No Net)"] Display["Display Driver Jail\n(No Net)"] OtherDev["Other Device Jails"] end end

subgraph GuestVM ["Read-Only Guest VM (Signed by Google)"] LinuxKernel["Guest Linux Kernel"]

subgraph LXDContainer ["Debian System Container (LXD)"] UserApps["Developer Tools & Apps\n(Unrestricted User / Root Access)"] end end

HostOS --- CrosvmPillars CrosvmPillars <-->|"Limited crosvm API"| LinuxKernel LinuxKernel --- UserApps ```

Dylan points out that securing this boundary is paramount: “So that cross-VM layer I was talking about, that's kind of the most important part of the security story here. It's the last line of defense before something gets into Chrome OS.”

---

[09:40](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=580s) Core Design Goals: Intuitive, Native, and Simple

Sudha Broslawsky returns to articulate the design philosophy that guides Crostini. Translating complex hypervisor and container machinery into everyday software required the team to establish three clear design pillars:

1. **Intuitive:** Developers have entrenched muscle memory, terminal habits, and workflow conventions built over decades. The environment must accommodate those expectations out-of-the-box so engineers feel immediately productive without learning esoteric Chrome OS workarounds. 2. **Native:** Instead of taking the easy technical route—such as booting a self-contained Linux desktop window that isolates users inside an awkward box—Google integrated Linux applications directly into the Chrome OS window manager, file picker, and application shelf. 3. **Simple:** All the complexity of virtualization, container lifecycles, and jail management is intentionally kept out of sight.

As Sudha summarizes the core philosophy: “Our guiding principle is that complexity shouldn't interfere with the user experience.” The user interface is intentionally built to mediate access gracefully, ensuring that security safeguards never degrade into friction that hinders everyday development.

[11:21](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=681s) File Sharing Architecture and the Threat Model

Tom Buckley frames the design challenge of Crostini as finding the sweet spot between developer flexibility and the established security patterns of Chrome OS. The first critical developer flow is accessing files: editors, compilers, and source control all require disk access. However, modern personal computers store far more than source code, holding tax returns, family photos, and unfinished novels. If an untrusted build tool or dependency compromises a developer's environment, standard OS setups leave all personal data vulnerable to ransomware, malicious data exfiltration, or spiteful deletion. Crostini is architected deliberately so untrusted code running inside Linux cannot reach host files unless explicitly permitted.

```mermaid flowchart TD accTitle: Crostini File Sharing Architecture accDescr: Diagram illustrating how files travel from Chrome OS to a Linux container through an isolated 9P server and VM. subgraph Host["Chrome OS (Host)"] FS["Host File System"] NineS["9s (Rust 9P Server in Jail)"] FS -->|"Explicitly Shared Folders"| NineS end

subgraph GuestVM["termina VM"] Mount9P["Kernel 9P Client Mount"] NineS -->|"9P Protocol"| Mount9P LXD["LXD Container Manager"] Mount9P --> LXD end

subgraph Container["penguin Container"] DevTools["Development Tools & Editors"] LXD -->|"Bind Mount"| DevTools end ```

Dylan Reid breaks down the layered implementation that enforces this boundary. Chrome OS shares selected directories out to the virtual machine using a custom 9P file server called `9s`. Because file sharing is a prime attack surface, the Chrome OS team authored `9s` from scratch in Rust to guarantee memory safety, thoroughly fuzzed it to ensure anomalous file inputs do not trigger exploits, and confined it in an extremely restrictive sandbox jail. The guest Linux kernel in the VM mounts the 9P export, and LXD then bind-mounts that directory into the default container where developer tools run. Even if an attacker completely subverts the Linux container, breaches the VM kernel, and exploits the server back into Chrome OS, the jailed server process itself only has file descriptors for the specific directories the user granted. As Dylan Reid emphasizes: “Because ultimately, we don't trust the code that's running inside this VM.”

- **`9s` Server:** Memory-safe 9P file server written in Rust, fuzzed against malicious input, and restricted to a sandboxed host jail. - **Layered Isolation:** Files traverse from Chrome OS host through `9s`, over the hypervisor boundary into the guest kernel's 9P client, and through LXD bind mounts to reach the container. - **Compromise Containment:** A catastrophic exploit spanning the container, VM, and file server still cannot access unshared host files, preventing ransomware or exfiltration of personal data.

---

[14:10](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=850s) User Experience: Seamless File Sharing in the Chrome OS UI

Sudha Broslawsky takes the stage to show how Crostini conceals the intricate pipeline of 9P mounts and container bind-mounts behind standard Chrome OS UI patterns. In the default configuration, users receive a dedicated folder in the Files app called "Linux Files," which maps directly to the user's home directory (`~`) inside the Linux container. Any file placed inside this folder is instantly readable and writable by Linux tools without security prompts. Everywhere else on the device—including local storage, external drives, and cloud files—remains completely invisible to Linux until the user grants explicit permission.

Granting access to external directories requires just two clicks. Broslawsky illustrates this by right-clicking a project folder named "Illustrations" in the Files app and choosing "Share with Linux." Notably, this folder resides directly in Google Drive, demonstrating that cloud-synced storage can be seamlessly forwarded into the local Linux environment; users can revoke access at any time through the Chrome OS Settings application. For quick one-off edits, Chrome OS provides implicit ephemeral sharing: double-clicking a file in the host "Downloads" folder that is associated with a Linux application, such as Visual Studio Code, launches the editor and shares that single file behind the scenes until the system restarts. Sudha Broslawsky notes the philosophy behind these choices: “This is the balance of security and simplicity we wanted to bring you.”

---

[15:46](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=946s) Web Development Flow: Securing Local Web Servers

Tom Buckley turns to the second core developer scenario: spinning up local web servers. Developing modern web applications requires running local HTTP and WebSocket servers, but raw low-level networking privileges present severe security vulnerabilities. A malicious process capable of listening to and binding arbitrary network traffic can potentially sniff outbound internet packets, observe the URLs a user navigates to in their primary browser, or even intercept session content. Crostini was engineered to let developers spin up development servers while completely walling them off from the host's actual network interfaces.

```mermaid flowchart LR accTitle: Crostini Web Server Port Forwarding accDescr: Flow diagram showing how HTTP traffic moves between Chrome and a containerized web server via VSOCK and background daemons. subgraph Browser["Chrome OS Host"] Chrome["Chrome Browser (localhost:PORT)"] HostDaemon["Host Forwarding Daemon"] Chrome <-->|"HTTP"| HostDaemon end

subgraph Guest["Termina VM / Container"] VMрез["VM Detection Daemon"] WebServer["Web Server (e.g.:8080)"] VMрез <-->|"Monitors Ports"| WebServer HostDaemon <-->|"VSOCK"| VMрез VMрез <-->|"HTTP"| WebServer end ```

Dylan Reid explains the underlying networking architecture. When a developer executes a command to run a web server inside a Crostini container, that server opens a port inside an isolated network namespace. That namespace is nested within the virtual machine, which is itself running inside a separate network namespace managed by the hypervisor (`crosvm`), entirely disconnected from Chrome OS host traffic. Because Chrome cannot natively route directly back into this multi-tiered namespace, Google built cooperating daemons into each layer. A daemon running inside the VM continuously monitors network namespaces to identify when a container opens a listening socket, bundles that metadata, and notifies a companion daemon on the Chrome OS host. The host daemon sets up local port forwarding, tunneling the connection over VSOCK—a dedicated socket protocol for host-to-guest VM communication. As Dylan Reid summarizes: “So the key here is that the web server gets to talk HTTP. Chrome gets to talk HTTP. Everything's normal.” Furthermore, Chrome OS marks these proxied `localhost` endpoints as trusted origins, allowing developers to test Progressive Web App (PWA) installation flows directly on their desktop.

- **Double Namespace Isolation:** Linux containers exist in a network namespace inside the VM, while the VM hypervisor network sits in a host namespace, preventing Linux code from sniffing host web traffic. - **Automated VSOCK Forwarding:** VM daemons automatically detect newly opened container listening ports and coordinate with Chrome OS daemons to bridge HTTP traffic over VSOCK without manual port mapping. - **Trusted Origin Support:** Proxied local ports are treated as secure local contexts, enabling full support for PWA desktop installs, service workers, and modern Web APIs.

---

[19:10](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=1150s) Testing Web Apps and PWAs via Localhost

Sudha Broslawsky proves how invisible this networking machinery is during day-to-day development. Navigating into a `PWA Starter Kit` directory within the Linux terminal, she executes the build script to start a local server listening on port 8080. Without configuring any iptables rules, editing hosts files, or tweaking IP addresses, the developer can simply open the Chrome browser on the host, type `localhost:8080`, and interact with the application.

To showcase platform versatility, Broslawsky arranges the screen with Chrome rendering the web application on the left and a native Linux build of Mozilla Firefox running on the right, verifying that cross-browser testing functions effortlessly on a single Chromebook. Importantly, this entire flow does not trigger a single security confirmation dialog or permission prompt. Because the connection direction flows exclusively from the secure host inward to the untrusted virtual machine—rather than the VM reaching out into host services—Chrome OS can safely permit the connection automatically. Reflecting on this architecture, Sudha Broslawsky notes: “This is because the host is accessing the VM and not the other way around.”

---

[20:30](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=1230s) Android Development and USB Device Forwarding

For the third developer flow, Tom Buckley addresses Android development. Having announced official Android Studio support for Chromebooks the prior day—complete with a dedicated one-click installer for Chrome OS—the team needed to ensure developers could deploy and debug apps on physical hardware. While wireless debugging via remote ADB over Wi-Fi is possible, developers expect the tactile convenience of plugging an Android phone directly into a USB port. However, USB is historically one of the most perilous peripheral interfaces in computing. Developers routinely connect thumb drives containing private data, fitness wearables storing sensitive health metrics, and hardware security keys guarding corporate accounts. Malicious or compromised software with direct access to a USB bus can track a user across machines via hardware serial identifiers, deploy firmware exploits, or manipulate peripheral memory.

Dylan Reid recounts that USB passthrough was one of the engineering team's most arduous undertakings. As Dylan Reid puts it: “Implementing USB was a lot of fun for us. It might have been our most painful stack.” The USB specification is notoriously massive and frequently implemented with subtle deviations across different hardware manufacturers. To defend the Chrome OS host kernel, the engineers isolated the USB virtualization driver inside a heavily sandboxed `crosvm` jail with zero access to the host file system or network interfaces. Instead of granting blanket access to the machine's physical USB controller, Crostini presents the Linux VM with an emulated, empty USB bus. Physical hardware remains completely invisible to the Linux environment until the user deliberately selects a specific peripheral to attach to the development container, ensuring that sensitive accessories like security tokens or mass storage devices remain strictly guarded by Chrome OS.

- **Official Android Studio Support:** Android Studio is packaged with a dedicated Chrome OS installer designed to streamline setup on Chromebooks. - **Physical USB Attack Surface:** Arbitrary USB bus access exposes users to machine tracking, peripheral firmware alteration, and compromise of connected security keys or storage media. - **Jailed Emulation:** The guest VM interacts exclusively with a virtualized USB bus managed within a jailed crosvm process, requiring explicit user permission before any physical USB device is passed through.

[23:00](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=1380s) USB Device Passthrough: Security, Privacy, and UX

Dylan Reid outlines how USB device passthrough operates across the Crostini virtualization stack. When a physical USB accessory is initially attached to the machine, the Linux environment does not see it at all—from the container's perspective, nothing is connected. Only when the user explicitly grants permission does the host attach the device to the virtual bus, expose it to the guest VM, and forward it down into the container.

```mermaid flowchart TD accTitle: USB Passthrough Flow accDescr: Step-by-step path of a physical USB device from host Chrome OS to the container.

subgraph Host["Host (Chrome OS)"] USB["Physical USB Device"] -->|"Plugged in"| CrOS["Chrome OS Kernel"] CrOS -->|"User prompted"| Dialog{"User Authorizes?"} end

subgraph VM["Termina VM"] Jail["Jailed Bus Controller (Rust)"] GuestKernel["Guest Linux Kernel"] end

subgraph Cont["Container"] LXC["Penguin (Debian Container)"] end

Dialog -->|"Yes"| Jail Jail -->|"Attach to virtual bus"| GuestKernel GuestKernel -->|"Forward device node"| LXC ```

Reid explains that the engineering team focused heavily on two core principles while designing this feature: security and privacy. To ensure security, the device handling code runs inside a Minijail environment to reduce the host attack surface, is implemented in Rust for memory safety, and is subjected to continuous fuzz testing. Privacy was an equally critical consideration: Reid emphasizes that untrusted code running inside a container must not be allowed to inventory connected peripherals, as peripheral lists can easily be used to fingerprint and track users across sessions.

- **Rust and Minijail:** The device emulation code is written in Rust to guarantee memory safety and runs within a sandbox jail to minimize attack exposure. - **Fuzzing:** Continuous fuzz testing is applied to identify vulnerabilities in the USB emulation layers. - **Fingerprint prevention:** Shielding device lists prevents rogue container code from harvesting hardware identifiers to track users.

[24:02](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=1442s) Demo: Android USB Debugging and Granular Access Control

Sudha Broslawsky takes the stage to present the final live demonstration, showing how secure USB passthrough works during real-world development. She connects an Android phone to a Linux-enabled Chromebook. As soon as the phone is plugged in, Chrome OS intercepts it and displays a notification banner asking the user whether to connect the device to Linux. At this stage, Chrome OS alone detects the hardware, while running a USB listing command inside the Linux terminal confirms that the container is entirely unaware of the device.

Once Broslawsky clicks the notification prompt to allow access, the device instantly registers inside Linux and appears in the terminal's USB device list. She switches over to Android Studio, runs an app project, selects the attached phone as the target, and watches the build deploy directly to the physical handset for testing and debugging. Users can open Chrome OS Settings at any time to inspect or revoke device permissions. Emphasizing the design philosophy behind this integration, Broslawsky highlights: “You, the user, are in full control at all times of what Linux has access to.”

- **Explicit notification prompt:** Devices remain completely hidden from the VM until the user explicitly permits the connection via a Chrome OS system notification. - **Android Studio deployment:** The user can instantly deploy, inspect, and debug mobile applications on physical Android hardware directly from the Linux container. - **Centralized Settings management:** Linux hardware permissions can be inspected, altered, or revoked at any point directly within Chrome OS Settings.

[25:54](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=1554s) Under the Hood: Termina, Crosh, and LXD Commands

Returning to the podium, Dylan Reid transitions from standard consumer workflows to the low-level developer hooks built into the platform. While the standard, polished experience meets the needs of most developers, Reid explains that Chrome OS retains built-in tools for advanced tinkerers who want to experiment under the hood. He enters the Chrome OS developer shell (Crosh) using `Ctrl`+`Alt`+`T`, highlighting the `vmc` utility introduced specifically to orchestrate virtual machines and container instances.

Running `vmc list` shows the installed virtual machines, displaying the default VM named `Termina`. Reid explains that while `vmc container` drops a user straight into the default `Penguin` Debian container, developers can also use `vmc start` to enter the `Termina` VM shell directly without invoking a container. Inside `Termina`, the LXD daemon manages containers, allowing users to leverage the standard `lxc` command-line tool. A simple `lxc list` command confirms that `Penguin` is running and displays its assigned IP address.

- **Crosh shortcut:** The developer shell is invoked from anywhere within Chrome OS using the key combination `Ctrl`+`Alt`+`T`. - **`vmc` utility:** The primary Chrome OS command-line tool used to create, list, start, and manage Crostini virtual machines. - **Default naming conventions:** The base Chrome OS virtual machine is titled `Termina`, while the default Debian-based development container inside it is named `Penguin`. - **Direct VM access:** Running `vmc start termina` accesses the intermediary VM environment where the LXD service runs.

[28:53](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=1733s) Container Management: Snapshots, Btrfs, and Custom Distros

Inside the `Termina` VM shell, Reid demonstrates the power and flexibility available through the LXD toolset. To safeguard work before attempting risky experiments or installing unstable packages, developers can execute `lxc snapshot <container-name> <snapshot-name>`. Because Crostini uses the btrfs filesystem inside the VM, snapshots rely on copy-on-write functionality, preserving storage space rather than duplicating entire container images. Users can run `lxc info` to view container details and snapshot history (complete with timestamps), and execute `lxc restore` to roll back changes whenever something breaks.

Reid goes on to show how to clone existing environments or run separate containers side by side for isolated toolchains—such as maintaining dedicated, segregated environments for Python 2.7, Python 3, Go, or Rust. He uses `lxc copy penguin kingfisher` to duplicate the default container into a new container named `Kingfisher`, starts it with `lxc start kingfisher`, and spawns an interactive shell inside it using `lxc exec kingfisher -- /bin/bash`. Finally, Reid demonstrates how developers can step outside Debian entirely. By tapping into Canonical's public image server, he installs and launches an Arch Linux container named `ArchTest`, verifying the distribution by running `pacman` instead of `apt`: “Look, it's actually Arch, I promise.”

| Command Example | Context | Purpose / Effect | |:--- |:--- |:--- | | `vmc list` | Crosh shell | Lists all Crostini virtual machines installed on Chrome OS (e.g., `Termina`). | | `vmc start termina` | Crosh shell | Enters the `Termina` VM directly without opening the inner container. | | `lxc snapshot penguin io1` | Inside `Termina` | Creates a lightweight, copy-on-write btrfs snapshot of the container state. | | `lxc info penguin` | Inside `Termina` | Displays container properties, IP addresses, resource usage, and snapshot list. | | `lxc restore penguin io1` | Inside `Termina` | Reverts the container back to the exact state captured in snapshot `io1`. | | `lxc copy penguin kingfisher` | Inside `Termina` | Clones the container `Penguin` into an independent instance named `Kingfisher`. | | `lxc exec kingfisher -- /bin/bash` | Inside `Termina` | Launches an interactive Bash shell within the specified container. | | `lxc launch images:archlinux archtest` | Inside `Termina` | Downloads and boots an official Arch Linux container image from Canonical's image server. |

[32:28](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=1948s) Community and Roadmap: The Future of Crostini

Tom Buckley closes the session by encouraging developers to explore the Crostini community. He points audiences directly to the Crostini subreddit (`/r/Crostini`), praising community members for their enthusiasm, their welcoming attitude toward Linux newcomers, and their uncanny ability to uncover new platform capabilities: “The folks there find features as soon as we release them, sometimes even sooner, and they're also really welcoming to new users of Linux on Chromebooks.”

Buckley summarizes the progress made with Linux on Chromebooks, emphasizing that the environment already delivers robust support for both Android and web development workflows. Looking ahead, the engineering roadmap includes expanding support for wider developer ecosystems and rolling out native UI support for features like multiple containers and integrated backup and restore mechanisms. Concluding the talk to audience applause, Buckley promises: “We're going to keep applying these principles of simplicity and security to give you the best developer experience possible.”

- **Community engagement:** The team actively points developers to the `/r/Crostini` subreddit for troubleshooting, feature discovery, and advanced configuration guides. - **Upcoming native features:** Forthcoming Chrome OS updates aim to bring multi-container orchestration and automated backup/restore functionality directly into the native graphical interface.

## Notable quotes > [09:40](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=580s) Our guiding principle is that complexity shouldn't interfere with the user experience. — Sudha Broslawsky

> [24:02](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=1442s) You, the user, are in full control at all times of what Linux has access to. — Sudha Broslawsky

> [02:46](https://www.youtube.com/watch?v=pRlh8LX4kQI&t=166s) You don't have to worry about malware accessing your files, snooping on your traffic, or infecting your peripherals. — Tom Buckley

## Mentioned Sudha Broslawsky, Dylan Reid, Tom Buckley, Google, Chrome OS, Crostini, Linux, Debian, crosvm, Rust, Canonical, LXD, 9s, Lenovo Yoga Book C630, Acer Chromebook Spin 13, Visual Studio Code, Android Studio, Mozilla Firefox, Termina, Penguin, Kingfisher, Arch Linux, Crosh, Minijail, Reddit

## Video description Learn how Linux for Chromebooks (Crostini) gives you a secure sandbox for development. Through a variety of demos, this talk will explain the architecture underlying Linux for Chromebooks and the design decisions that keep it easy to use.

Watch more #io19 here: Web at Google I/O 2019 Playlist → https://goo.gle/io19web Google I/O 2019 All Sessions Playlist → https://goo.gle/io19allsessions Learn more on the I/O Website → https://google.com/io

Subscribe to the Chrome Developers Channel → https://goo.gle/ChromeDevs Get started at → https://www.google.com/chrome/dev/

Speaker(s): Dylan Reid, Tom Buckley, Sudha Broslawsky

TD69F6 event: Google I/O 2019; re_ty: Publish; fullname: Dylan Reid, Tom Buckley, Sudha Broslawsky;

[Source](https://www.youtube.com/watch?v=pRlh8LX4kQI)