ChromeOS is one of the very few operating systems, which silently auto-updates itself every couple of weeks without explicitly notifying or seeking permission from the user. Its able to do so because its designed to be quick, efficient and 100% fail-proof. This post will go into the details of those key design elements and how its revolutionizing how modern internet connected devices should update.
Silent Auto-Update is the key
Most folks in the IT industry have a love/hate relationship with OS updates.
On one hand its critical to ensure that their users are always protected against the latest threats. Device manufactures are constantly playing the whack-a-mole game with security bugs and landing them on the devices in a timely manner is critical for most businesses.
On the other hand, deploying patches often requires a long wait time to download+apply and then a reboot after which you have to pray that the device would come up without any problems. To make things worse all this has to be done across hundreds if not thousands of devices across the network and IT admins hope that they wont be called to the CEO’s office for bricking the fleet.
ChromeOS is one of the very few operating systems which is reliable enough that it can silently update without having to request the user. And this is one of the key reasons why the OS is often looked on as one of the most secure Operating systems today.
ChromeOS AutoUpdate design goals
Silent AutoUpdate is just one of the intentional design attributes of how ChromeOS does its updates. Here are some of the other interesting goals of this infrastructure
- User data shouldn’t be part of the root partition which is updated by updater – User data is on a separate partition. In fact every user gets their own “CryptoHome” which is encrypted with their own password so that no one else can get access to it without knowing your password.
- This allows the primary root partition to be mounted as Read-only. This is a huge security feature since it dramatically limits what a malware can do to the root file system which hosts the OS.
- And since the root partition is Read-only, AutoUpdater cannot modify it. Instead it uses a copy of the root file system on a separate partition to apply the updates – Not touching the currently active OS image, allows the user to use the device with almost no impact. There is a tiny computational impact of actually downloading and applying the update.
- The system should allow delta-updates – The entire OS is a couple of GB, but the updates don’t have to be that big. Most devices download significantly smaller update payload which may just be few MBs in size.
- The system should be able to apply updates quickly – Even though its already silent, design requires it to be optimized for time it takes to complete the update process
- The device should have fail-safe to rollback to previous version if something fails – This feature is possible because all ChromeOS devices always have two copies of the OS and it can quickly fall back to older version if the new version cannot boot up.
- The update should only take one reboot to apply.
- Finally, the root OS image should be bit-by-bit identical to the original image on the server. This is such a critical element of the update design that if even a single bit is modified unintentionally, the boot partition will fail to boot. ChromeOS uses something called verified boot to enforce this.
Getting the updates
If you are managing the ChromeOS device, you should review my post about how to manage AutoUpdates. The policies pushed to the device can change the behavior I describe below.
Unmanaged ChromeOS devices automatically contact update servers every 45 minutes to check if there is an update available. The request sent to the server has the exact model of the device, the current version and information of any policies set on the device. The server uses that information to find the best matching update for the device. If it finds one, it will also check if a “delta” package is available which could significantly reduce the time to download the update.
Here are some fun facts about this process
- While HTTPS is used to fetch these updates, ChromeOS will infrequently look for updates using HTTP in case its running on a network which requires custom root certs which may be breaking HTTPS transport layer
- ChromeOS has a P2P file sharing layer built into it which it uses to share OS updates as well. But to use this you need two important things (i) Your network should allow multicast traffic to talk to each other (ii) You should have other devices of the same exact model/type for the updates to be shared.
- Getting a “delta” update instead of the full OS image is significantly faster to download. However, if you are behind by more than a few Major versions, you will most probably get a full image instead. To avoid this try to use the device every few weeks to allow it to update using deltas.
- If you setup the policy to use HTTP to fetch updates and if you have proxy servers in your network, you can configure it to cache the payloads. This is how a lot of schools with 1000s of students manage AutoUpdate distribution. Caching on the edge device can significantly reduce the network bandwidth needed for the updates.
- For an OS update to be considered successful a device has to fully boot up and connect to the network. If a new update fails to boot up 6 times in a row, that OS image is considered unusable and BIOS will switch back the device to the previous OS image.
- Final fact: ChromeOS updater applies the changes directly to the final root partition. This is significantly more space efficient as it doesn’t need a separate location to store the payload before its used to install.
I’ve had the luxury of having worked with many operating systems in my life. I’ve played with OSX, AIX, Windows, MacOS, Linux and a bunch of others which I’ll not name. Every single successful OS had one key feature which made it successful. I’ve used and deployed ChromeOS for over 10 years now, and I can tell you this is just the beginning. ChromeOS and ChromeOS Flex with its ability to silently AutoUpdate is “the” killer feature which will make it succeed like all other successful Operating systems before it.