Is ChromeOS the most advanced OS on the market today?
In 1991, Digital Equipment Corporation [DEC] cancelled the VAX VMM engineered system programme - just as it was reaching market readiness. The VAX VMM proposition presented a sophisticated, US Department of Defense Orange Book level A1 capable Multi Level Security (MLS) computer system.
DEC had invested considerable effort into developing the VMM computer OS, and closely integrating it with the VAX-series minicomputer hardware platform, to make a robust, highly secure solution for enabling concurrent processing of different classifications of data, compliant with the Biba or the Bell-LaPadula integrity models, all in the one computer system.
The reasons for the programme being cancelled are unclear, but it is speculated that the computing price-crash induced in the late 1980s by generic IBM PC clone manufacturers like Compaq and Dell made the MLS idiom obsolete. It was far cheaper to buy your workers (eg.) five desktop PCs, one for each level of classified data that needed to be processed, and manage five associated dedicated networks, than to buy a single MLS computer — the so-called MSL or “Multiple Single Level” way of managing classified data processing.
VAX VMM initially started development in 1981 as a Type 1 Virtual Machine Monitor implementation, as a response to the IBM KVM/370 system, and was essentially an early, production ready Virtual Machine Hypervisor implementation. The VAX VMM Security Kernel was capable of running multiple OSs, specifically VMS and Ultrix, and implemented mediated access to physical system resources (disk, memory, display etc.) via an additional (virtual) processor ring which was used to enforce mandatory access control policy on any sensitive processor instructions invoked by a guest OS via a hardware emulation layer, instead of directly accessing host system resources via direct calls to the kernel (it should be fairly noted that Type 2 VMMs like Linux LXC, Solaris Zones or BSD Jails, adopt this approach).
Now, if we fast forward 30 years to 2020, we can see that there are some striking similarities between the VAX VMM MLS architecture and Google’s ChromeOS operating system. Whilst many Chromebook models are some of the cheapest general purpose computers available on the mass market today, they do appear to be highly influenced by the MLS architecture of the (too expensive to bring to market) VAX VMM system. ChromeOS offers a fully integrated Linux experience, including seamless support for graphical, windowed applications via containers.
Google ChromeOS was intially forked from Ubuntu, but has evolved over time into a completely different beast. It includes an integrated, cutdown custom hypervisor (crosvm — The Chrome OS Virtual Machine Monitor), written in the type-safe language Rust, capable of running multiple VMs, treating everything within the guest VM as untrusted, and exposing sandboxed virtualized devices to defend the kernel from attack — each virtual device is run in a “minijail” sandbox defined by a Linux seccomp mandatory access control policy. The guest VMs are a readonly image running a security hardened Linux kernel, whilst the user environment itself is an unprivileged LXC container running within a guest VM.
Whilst ChromeOs’ crosvm virtual machine monitor relies on the Linux KVM (Kernel Virtual Machine) module, which as the name might suggest, is a Type 2 virtual machine monitor where the host kernel is involved in the setup and execution of guest VMs, ChromeOS uses Paravirtualized device access via VirtIO, whereby the guest VM knows that it is virtualized. This means the system is using memory-backed buffers as asynchronous communication queues between guest VM and hypervisor in order to efficiently communicate IO requests without compromising performance, in a manner somewhat similar to the virtual processor ring feature of VAX VMM.
ChromeOS might still have a way to go before it would win an Orange Book A1 accolade, but it is surely the most robust mass market computer OS available today. But there is certainly some room for improvement:
* Android applications currently run directly on the host kernel in an LXC container, not in a VM
* The main windowing system and the Chrome browser are run directly on the host, but could this also be moved to a guest VM container perhaps running an adapted implementation of virtio_wl (Google’s Wayland VirtIO kernel module for guest VMs), or alternatively proxying the guest Wayland client but to a totally stripped down host implementation?
Why is this relevant?
Well, current research into IT expenditure suggests that 80–90% of global IT expenditure is in system maintenance, primarily of legacy IT systems, some of which are 60 years old, or more. This expenditure is only getting bigger each year, as both the systems and the knowledge to support them become more and more antiquated with time. Most universities (with some notable exceptions in SE India) stopped teaching COBOL decades ago, and yet billions of lines of code written in COBOL are executed every single day in diverse systems across government and the private sector.
It has reached the point, that current trends in computer engineering thought leadership are to completely reconsider systems design and engineering with a view to maintenance, so that both existing contemporary, and future to-be IT systems can be made to endure for a century or more. This effectively means that bringing to massmarket desktop and server systems that exhibit modularity, support encapsulation, and implement MLS virtualization of untrusted compute systems are critical challenges that will need to be addressed in the next five-ten years, in order to tame the cost of IT maintenance into the future.
So in this sense, Google’s ChromeOS is about 5 years ahead of the market and accelerating, as the most robust computing platform available today that natively offers modularity, encapsulation, and sandboxed virtualization of untrusted compute systems.
