Linux

Internals deep dive

ChromeOS supports running arbitrary code inside of VMs⁠. This is the low-level documentation on that support; for a more user-friendly view, see the faq

Prerequisites

Ensure that your ChromeOS device supports Linux on ChromeOS⁠
Make sure you’re running ChromeOS release 72 (M72+) or greater (released February 2019).
- Start a system update⁠ if need be and reboot.
- This should work in the stable channel⁠.
- You do not need to put it into developer mode.
Enable the Linux container

Runtime features

You should expect the following features to work when running your Linux container:

Outbound network connections (IPv4).
Unaccelerated graphics.
Accelerated graphics (via OpenGL).
Wayland⁠ programs (preferred; via Sommelier⁠).
X⁠ programs (compatibility via Sommelier⁠ and XWayland⁠).
Audio output in M74+ and experimental capture/microphone⁠ in R79+ images.

Missing features

There‘s a lot of low-hanging fruit we’re working on fleshing out. A couple of clear examples are:

Video hardware decoding.
IMEs⁠.

While there are more things being considered, the ChromeOS team takes a measured approach to rolling out new features in order to ensure overall system security isn’t compromised. See the Crostini FAQ for more detailed information that cover most topics around Linux on ChromeOS development.

Security

While running arbitrary code is normally a security risk, the ChromeOS team believes the runtime model employed by Linux on ChromeOS container sufficiently mitigates and contains that security risk. The virtual machine⁠ (VM) is the security boundary, and everything inside of it is considered untrusted. The current VM guest image is also running a custom-hardened kernel to further improve the security of the containers, but that is considered a nice feature to have rather than it being relied on to ensure overall system security.

In this model, the rest of the ChromeOS system should remain protected from arbitrary code (malicious or accidental) that runs inside of the containers inside of the VM.

The only contact with the outside world is via crosvm⁠, and each channel talks to individual processes (each of which are heavily sandboxed).

User data in the container

With the shift to cloud services, current security thinking highlights the fact that getting account credentials (e.g. your Google/Facebook passwords⁠) is a more lucrative attack vector than attacking your desktop or laptop. They are not wrong. The current VM/container ChromeOS solution does not currently improve on this. Put plainly, anything entered into the container is the responsibility of the user currently. So, if you run an insecure or compromised container, and then type your passwords into the container, they can be stolen even while the rest of the ChromeOS system remains secure.

Process persistence

Processes in VMs and containers do not survive logout (since they live in the user‘s encrypted storage) and are killed automatically. They also do not automatically start at login (to avoid persistent attacks), nor can they automatically run at boot (without a login session) since they wouldn’t be accessible (as they‘re in the user’s encrypted storage).

Executable and writable code

The Termina⁠ VM disk image is downloaded to the writable stateful partition like other Chrome components⁠. In order to make sure the contents aren’t modified, dm-verity⁠ is used. This also means only images signed by Google may be loaded, and the image is always read-only.

Hardware attacks

The Meltdown/Spectre vulnerabilities have implications for safely using VMs. We‘ve applied fixes and mitigations to make sure VMs can’t attack the host system or other VMs. See the Chromium OS wiki page on the Meltdown and Spectre vulnerability status for ChromeOS devices⁠ for more details.

Lifecycles

Once you’ve enabled the Linux container (which takes care of installing all the other necessary components like Termina), the system is ready to use.

While these components may be installed, nothing starts running right away. When you log out, everything is shut down and killed, and when you log in, nothing is automatically restarted.

When you run the Terminal app, or any other Linux app that starts the container, and its parent container isn’t running yet, the Termina VM will be started automatically, and the default Linux on ChromeOS container (also known as Crostini) will be started in that. This allows you to connect to the container via SSH or SFTP (via the Files app).

When you close all visible applications, the VM/containers are not shut down. If you want to, you can manually stop and start them, as well as spawn more containers than just the default one.

Data persistence

All of the VMs and containers created, and the data within those containers, will persist across user sessions (logout/login). They are kept in the same per-user encrypted storage as the rest of the browser’s data.

If a VM or container is stopped or killed ungracefully (e.g. powerloss), then data might be lost and need recovery like anything else in the system.

Device support

While the desire is to have Linux on ChromeOS work with all Chromebooks, the required kernel and hardware features limit where it can be deployed. The team has focused on system security and stability while backporting features where it makes sense. This is an area of ongoing effort.