Chrome Operating System

DIPLOMA IN TECHNICAL TEACHER EDUCATION
DEPARTMENT OF COMPUTER STUDIES
UNIT: OPERTING
SYSTEM TASK: TERM
PAPER TITLE:
“PATHFINDER”
By
KARL IAN KIPRUTO
K. CLASS :2019CSCS1A
ADM NO:2019CS135018
(karlkibet@gmail.com , karlkibet@yahoo.com , karlkibet@hotmail.com )
SUBMITTED TO
LECTURER: MR. OKIDIA YONA
DATE: 28TH JUNE 2019
Abstract
Due to the increase nature of computer threats and attacks, the security of the operating system is
paramount in the computing world today. Every modern computer system, from network servers,
workstation desktops, to laptops and hand-held devices, has a core piece of software, called operating
system (OS) executed on the top of a bare machine of hardware that allocates the basic resources of
the system and supervises the execution of all applications within the system. This paper investigates
and evaluates the security of Google Chrome Operating System. Google Chrome Operating system is
an operating system developed by google, which runs on specialized hardware. The Chrome OS differ
from traditional operating system such as Windows in that it is designed to work specifically with web
applications. In this operating system, the user data lives essentially on the web. Thus, if the physical
machine-laptop is lost or stolen, the user can still access their data online. However, the Chromebook
also allows users to access downloaded data offline, which must be kept safe. To achieve this, Chrome
OS ensures that all downloaded data is protected and that code running on this Chromebook is safe to
use. In order to avoid security challenges of traditional operating system such as virus and worms,
Chromebook not only ensures that the code is safe, but also incorporates an auto update features to
add new patches to the system.
Keywords: architecture, Security, Google Chrome, Web, Operating System, Chrome OS,
cloud, Linux, open source. Cloud computing, netbook
ii | P a g e OS TERM PAPER BY KARL IAN karlkibet@gmail.com

Acknowledgement
On every step there is a need of guidance and support. Therefore, I would like to thank anybody who
supported me in completion of this term paper. There is always a sense of gratitude towards those
persons who helped me directly or indirectly inspired, directed and helped me towards completion
this term paper report.
I am extremely grateful and remain indebted to lecturer Mr. Okidia for being a source of inspiration
and for his constant support in the Design, implementation and evaluation of the term paper. The
constant constructive criticism and invaluable suggestion, which benefited me a lot while
developing the Term paper on “Chrome Operating System”.
Last but not the least, I would like to thank my family, my classmates and my friends, for giving all
the things that needed to me at the first place and supporting me intellectually spiritually throughout
my entire period of preparing this Paper.
iii | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

Abbreviations Used in this Term Paper
OS: operating system

I/O: input output
CPU: central processing unit
iv | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

CHAPTER ONE
INTRODUCTION
Operating System
An operating system (OS) is a collection of software that manages computer hardware resources
and provides common services for computer programs. The operating system is an essential
component of the system software in a computer system. Application programs usually require an
operating system.
These days, computing is a Web-centric experience, and you perform many of your Internet tasks
through, may be a program such as Firefox or Internet Explorer, helps you retrieve information from
the Internet multiple times per day, integrate it with other online documents and share data galore
with people all over the planet. Google is trying to reshape the computer experience by using its
understanding of the Web to create the new Chrome operating system (OS) that will pave way for
instant access of many services and applications (alias Pathfinder).
Traditional operating systems, such as Windows, require a lot of hard drive space and demand some
work on your part. You have to install the programs you want individually, to manage OS and
security updates and manage device drivers, too. Google’s Chrome OS aims to overhaul that
paradigm. With Chrome, the browser actually is the OS - in this case, the Chrome OS builds on the
Google browser of the same name. In total, the Chrome OS is built on an open-source version of
Linux and integrated with the Chrome browser, a simple media player and that's it. Google
embraced the concept of an ultra-simple Web-centric OS in large part due to the huge recent success
of netbooks.
Netbooks are small laptop computers that are designed to let users access the Web, and not much
more; they're inexpensive and feature-limited hardware Google announced Chrome OS on July 7,
2009, describing it as an operating system in which both applications and user data reside in the
cloud. The concept was new enough to confuse users and analysts, as well as Google cofounder
Sergey Brin, who, at first, did not realize his data did not reside on his personal computer, but could
be accessed from any machine running the operating system. To ascertain marketing requirements,
the company relied on informal metrics, including monitoring the usage patterns of some 200
Chrome OS machines used by Google employees. Developers also noted their own usage patterns.
Matthew Papakipos, former engineering director for the Chrome OS project, put three machines in
his house and found himself logging in for brief sessions: to make a single search query or send a
short email.
1|Page OS TERM PAPER BY KARL IAN karlkibet@gmail.co

On November 19, 2009, Google released Chrome OS's source code as the Chromium OS project. As
with other open source projects, developers can modify the code from Chromium OS and build their

own versions, whereas Chrome OS code is only supported by Google and its partners and only runs
on hardware designed for the purpose. Unlike Chromium OS, Chrome OS is automatically updated
to the latest version thus first boot up
At a November 19, 2009 news conference, Sundar Pichai, the Google vice president overseeing
Chrome, demonstrated an early version of the operating system. He previewed a desktop which
looked very similar to the Chrome browser, and, in addition to the regular browser tabs, also had
application tabs, which take less space and can be pinned for easier access. At the conference, the
operating system booted up in seven seconds, a time Google said it would work to reduce.
In summary, Google Chrome OS is a Linux-based operating system designed by Google to work
primarily with web applications. The user interface takes a minimalist approach and consists almost
entirely of just the Google Chrome web browser, since the operating system is aimed at users who
spend most of their computer time on the Web, the only "native" applications on Chrome OS are a
browser, media player and file manager. This means that Chrome OS is almost a pure web thin
client OS.
Difference between Google Chrome OS and Chromium OS

Google Chrome OS is to Chromium OS what Google Chrome browser is to Chromium. Chromium
OS is the open source project, used primarily by developers, with code that is available for anyone
to checkout, modify and build their own version with. Meanwhile, Google Chrome OS is the Google
product that OEMs will ship on Netbooks this year. Specifically, Google Chrome OS will run on
specially optimized hardware in order to get enhanced performance and security. Chromium OS
does not auto-update (so that we do not blow away any changes you may have made to the code)
while Google Chrome OS will seamlessly auto-update so that users have the latest and greatest
features and fixes. Google Chrome OS will be supported by Google and our partners, whereas
Chromium OS is supported by the open source community, but they fundamentally share the same
code base. Google Chrome OS also has some cool firmware features, verified boot and easy
recovery, which require corresponding hardware changes and thus also don't work in Chromium OS
builds.
What is Cloud Computing?

Cloud Computing is Internet-based computing, whereby shared resources, software, and information
are provided to computers and other devices on demand, like the electricity grid.
Cloud computing is a paradigm shift following the shift from mainframe to client–server in the early

1980s. Details are abstracted from the users, who no longer have need for expertise in, or control
over,

the technology infrastructure "in the cloud" that supports them. Cloud computing describes a new
supplement, consumption, and delivery model for IT services based on the Internet, and it typically
involves over-the-Internet provision of dynamically scalable and often virtualized resources. It is a
byproduct and consequence of the ease-of-access to remote computing sites provided by the
Internet. The term "cloud" is used as a metaphor for the Internet, based on the cloud drawing used in
the past to represent the telephone network, and later to depict the Internet in computer network
diagrams as an abstraction of the underlying infrastructure it represents. Typical cloud computing
providers deliver common business applications online that are accessed from another Web service
or software like a Web browser, while the software and data are stored on servers.
Most cloud computing infrastructures consist of services delivered through common centers and
built on servers. Clouds often appear as single points of access for all consumers' computing needs.
What is a Netbook?
Netbooks (sometimes also called mini notebooks or ultra-portables) are a branch of subnotebooks, a
rapidly evolving category of small, lightweight, and inexpensive laptop computers suited for general
computing and accessing Web-based applications; they are often marketed as "companion devices",
i.e. At their inception in late 2007 — as smaller notebooks optimized for low weight and low cost —
netbooks omitted certain features, featured smaller screens and keyboards, and offered reduced
specification and computing power. Over the course of their evolution, netbooks have ranged in size
from below 5" screen diagonal to over 11.6". A typical weight is 1 kg. Often significantly less
expensive than other laptops, by mid-2009, some wireless data carriers began to offer netbooks to
users "free of charge", with an extended service contract purchase.
History
Chrome OS's origins are unclear. Jeff Nelson, a former Google engineer, claimed to have developed
the original technology, code named "Google OS", described as "a webapp-centric chopped-down
Linux with a Chrome browser front-end". As proof, Nelson cited a patent filed by Google in March
2009, listing Nelson as the inventor, entitled "Network-based Operating System Across Devices". In
a discussion on Google+ in February 2013, Nelson wrote that by the end of 2007, after a series of
meetings, he and a product manager had convinced "management to launch the Chrome OS project
and assign head count". Other Google employees disputed his claim, including Antoine Labour, who
was one of the three original engineers on the Chrome OS project. Labour wrote in the February
2013 Google+ discussion that he had never heard of Nelson, and that Nelson's work on a Linux
distribution "based on the concept of running off of a ram disk" has "pretty much nothing to do with

Chrome OS."

A ZDNet article by Steven J. Vaughan-Nichols, published in March 2013, also cast doubt on
Nelson's claim, quoting an unnamed source at Google as saying that Nelson "was not involved with
the Chrome OS project at any point of time nor was Chrome OS inspired by his work." According to
Vaughan- Nichols, Chrome OS "seems to have started with Ubuntu Linux.
On November 19, 2009, Google released Chrome OS's source code as the Chromium OS project. As
with other open source projects, developers can modify the code from Chromium OS and build their
own versions, whereas Chrome OS code is only supported by Google and its partners and only runs
on hardware designed for the purpose. Unlike Chromium OS, Chrome OS is automatically updated
to the latest version.
Reception
At its debut, Chrome OS was viewed as a competitor to Microsoft, both directly to Microsoft
Windows and indirectly the company's word processing and spreadsheet applications—the latter
through Chrome OS's reliance on cloud computing. But Chrome OS engineering director Matthew
Papakipos argued that the two operating systems would not fully overlap in functionality because
Chrome OS is intended for netbooks, which lack the computational power to run a resource-
intensive program like Adobe Photoshop.
We can already do most, if not all, of what Chrome OS promises to deliver. Using a Windows 7 or
Linux-based netbook, users can simply not install anything but a web browser and connect to the
vast array of Google products and other web- based services and applications. Netbooks have been
successful at capturing the low-end PC market, and they provide a web-centric computing
experience today. I am not sure why we should get excited that a year from now we'll be able to do
the same thing, but locked into doing it from the fourth-place web browser.

The file manager in Chrome OS showing a mounted Google Drive.
Google developers began coding the operating system in 2009, inspired by the growing popularity
and lower-power consumption of netbooks, and the realization that these small laptops had gotten
their name from their primary use: accessing the Internet. To ascertain demand for an operating
system focused on netbook Web transactions, the company eschewed the usual demographic
research generally associated with a large software development project. Instead, engineers have
relied on more informal metrics, including monitoring the usage patterns of some 200 Chrome OS
machines used by Google employees. Developers also noted their own usage patterns. Matthew
Papakipos, engineering director for the Chrome OS project, put three machines in his house and
found himself logging in for brief sessions: to make a single search query or send a short email.

CHAPTER TWO
PART ONE:
Design Principles
Early in the project, Google put online many details of Chrome OS's design goals and direction.
However, the company has not followed up with a technical description of the completed operating
system. Design of Google OS are under following points
User interface
Design goals for Google Chrome OS's user interface include using minimal screen space by
combining applications and standard Web pages into a single tab strip, rather than separating the
two. Designers are considering a reduced window management scheme that would operate only in
full- screen mode. Secondary tasks would be handled with "panels": floating windows that dock to
the bottom of the screen for tasks like chat and music players. Split screens are also under
consideration for viewing two pieces of content side-by-side. Google Chrome OS will follow the
Chrome browser's practice of leveraging HTML5's offline modes, background processing, and
notifications. Designers propose using search and pinned tabs as a way to quickly locate and access
applications.

10 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co
Remote application access
In June 2010, Google software engineer Gary Kačmarčík wrote that Chrome OS will access remote
applications through a technology unofficially called "Chromoting", which would resemble
Microsoft's Remote Desktop Connection.
New window manager and graphics engine
On April 10, 2012, a new build of Chrome OS offered a choice between the original full-screen
window interface and overlapping, re-sizable windows, such as found on Microsoft Windows and
Apple's Mac OS X. The feature was implemented through the Ash window manager, which runs
atop the Aura hardware-accelerated graphics engine. The April 2012 upgrade also included the
ability to display smaller, overlapping browser windows, each with its own translucent tabs, browser
tabs that can be "torn" and dragged to new positions or merged with another tab strip, and a mouse-
enabled shortcut list across the bottom of the screen. One icon on the task bar shows a list of
installed apps and bookmarks. Writing in CNET, Stephen Shankland argued that with overlapping
windows, "Google is anchoring itself into the past" as both iOS and Microsoft's Metro interface are
largely or entirely full-screen. Even so, "Chrome OS already is different enough that it's best to
preserve any familiarity that can be preserved".
Design Goals and Direction

Minimum Booting Time
One of the Chrome’s best features is that its booting time is minimum. It claims to boot in 7
seconds.
Goals for the drive partitioning scheme are as follows:
 Speed - Support fast boot, where the boot loader is part of the firmware.
 Simplicity - Support auto update.
 Robustness - Recover from failed updates or corrupt partitions.
 Openness - Allow developers to run OSs other than Google Chrome OS.
Goals for the boot process are as follows:
 Support readily available development platforms so that Chromium OS software can
be built and tested without waiting for final hardware/firmware.
 Support a limited selection of off-the-shelf netbooks for internal trials of Chromium
OS.
Provide a secure and verifiable boot path for official Google Chrome OS devices.

Architecture
In preliminary design documents for the Chromium OS open source project, Google describes a
three- tier architecture: firmware, browser and window manager, and system-level software and
userland services.
The firmware contributes to fast boot time by not probing for hardware, such as floppy disk drives,
that are no longer common on computers, especially netbooks. The firmware also contributes to
security by verifying each step in the boot process and incorporating system recovery.
System-level software includes the Linux kernel that has been patched to improve boot performance.
Userland software has been trimmed to essentials, with management by Upstart, which can launch
services in parallel, re-spawn crashed jobs, and defer services in the interest of faster booting.
The window manager handles user interaction with multiple client windows much like other X
window managers.
Hardware Support
Google Chrome OS is initially intended for secondary devices like netbooks, not a user's primary
PC, and will run on hardware incorporating an x86 or ARM. While Chrome OS will support hard
disk drives, Google has requested that its hardware partners use solid-state drives due to their higher
performance and reliability, as well as the lower capacity requirements inherent in an operating
system that accesses applications and most user data on remote servers. Google Chrome OS
consumes one- sixtieth as much drive space as Windows 7.
Companies developing hardware for the operating system include Hewlett-Packard, Acer, Adobe,
Asus, Lenovo, Texas Instruments, Freescale, Intel, Samsung Australia and Qualcomm.
In December 2009, Michael Arrington of TechCrunch reported that Google has approached at least
one hardware manufacturer about building a Google-branded Chrome OS netbook. According to
Arrington's sources, the devices could possibly be configured for mobile broadband and be
subsidized by one or more carriers.
Printing
Google Cloud Print is a Google service that helps any application on any device to print on any
printer. While the cloud provides virtually any connected device with information access, the task of
"developing and maintaining print subsystems for every combination of hardware and operating
system – from desktops to netbooks to mobile devices – simply isn't feasible. “However, the cloud
service would entail installing a piece of software, called a proxy.

Integrated media player
Google will integrate a media player into both Chrome OS and the Chrome browser, enabling users
to play back MP3s, view JPEGs, and handle other multimedia files while offline.
Link handling
One unresolved design problem related to both Chrome OS and the Chrome browser is the desired
behavior for how Web applications handle specific link types. For example, if a JPEG is opened in
Chrome or on a Chrome OS device, should a specific Web application be automatically opened to
view it, and if so, which one? Similarly, if a user clicks on a .doc file, which website should open:
Office Live, Gview, or a previewing utility? Project director Matthew Papakipos noted that
Windows developers have faced the same fundamental problem: "Quicktime is fighting with
Windows Media Player, which is fighting with Chrome". As the number of Web applications
increases, the same problem arises.
Security
In March 2010, Google software security engineer Will Drewry discussed Chrome OS security.
Drewry described Chrome OS as a "hardened" operating system featuring auto-updating and
sandbox features that will reduce malware exposure. He said that Chrome OS netbooks will be
shipped with Trusted Platform Module (TPM), and include both a "trusted bootpath" and a physical
switch under the battery compartment that actuates a developer mode. That mode drops some
specialized security functions but increases developer flexibility. Drewry also emphasized that the
open source nature of the operating system will contribute greatly to its security by allowing
constant developer feedback.
Shell access
Chrome OS includes the Chrome Shell, or "crosh", which offers minimal functionality such as ping
and SSH, but no Bash-like shell abilities. In developer mode, a full-featured Bash shell can be opened
via VT-2, and is also accessible via the crosh command "shell".
Release channels and updates
Chrome OS uses the same release system as Google Chrome: there are three distinct channels:
Stable, Beta, and Developer preview (called the "Dev" channel). The stable channel will be updated
with features and fixes once they have been thoroughly tested in the Beta channel, and the Beta
channel will be updated roughly monthly with stable and complete features from the Developer
channel. The Developer channel is where ideas get tested, and sometimes fail, and can be very

unstable at times.

Chrome OS on Windows 8
On Windows 8, exceptions allow the default desktop web browser to offer a variant that can run
inside its full-screen "Metro" shell and access features such as the Share charm, without necessarily
needing to be written with Windows Runtime. Chrome's "Windows 8 mode" was previously a tablet-
optimized version of the standard Chrome interface. However, in October 2013, the mode was
changed on Dev channel to offer a variant of the Chrome OS desktop.
Some Others
In April 2012, Google made the first update to Chrome OS's user interface since the operating system
had launched, introducing a hardware-accelerated window manager called "Aura" along with a
conventional taskbar. The additions marked a departure from the operating system's original concept
of a single browser with tabs and gave Chrome OS the look and feel of a more conventional desktop
operating system. "In a way, this almost feels as if Google is admitting defeat here", wrote Frederic
Lardinois on TechCrunch.
PART TWO:
Internal Design
User Applications
The Google Chrome Operating System’s architecture can be divided up into four separate layers. The
first is the User Application’s layer. Applications are written mainly in Java Based such as JVM, Java
servlets, JavaScript and Ruby. Applications run in The Sandbox which provides a protective
environment which does not rely on the Hardware Layer, instead it provides an abstraction that does
not care for the hardware specifics. Applications such as Chrome Browser, Chrome Web Store,
Gmail, Games, Google Calendar, Google Maps, Google Play Music, Netflix, and YouTube all come
standard when on Chromebooks and Chrome boxes
Operating System Services
The operating system offers services to programs and the user whom are executing the programs.
The services that are offered can be broken down into six main categories.
User Interface
Google Chrome Operating System offers both the Command Line Interface and the Graphical User
Interface. The Command Line Interface allows the user to enter input through the keyboard as text
commands. The Graphical User Interface is a windowing system with a touchpad/mouse that allows
the user to enter I/O, virtually touch software, and enter input through the keyboard.

Program Execution
Program Execution allows The Google Chrome Operating System to transfer a program to memory,
execute the program, and finally end the program.
PART THREE:
I/O OPERATIONS
Many Programs often have the need for I/O, where I/O devices or files are involved. For these
devices, specific functions are often needed such as burning a disk. Because I/O devices are
normally not accessible to the user, for both security reasons and from a productivity viewpoint,
they are handled by The Google Chrome Operating System.
File System Manipulation

Programs have the quintessential need to write to files, read, create, delete, search, and list files. The
Google Chrome Operating System provides a set of file systems to cater to the user’s decision,
individual functions, or efficiency.
Communications
Processes often need to communicate with each other. The Google Chrome Operating System
provides the communication feature through shared memory, where packets are sent to and from
processes.
Error Detection
Google Chrome Operating System is always checking for errors, whether it be a CPU error, memory
errors, I/O errors, and the applications. Because Google Chrome Operating System is constantly
updating it always had the most up to date error detection tools.
Kernel
Google Chrome Operating System utilizes the new 3.4.6 Linux kernel. The kernel provides a virtual
environment in order to create an abstraction of the hardware layer. The kernel provides services
such as the Process Scheduler, Memory Manager, Virtual File System, Network Interface, and Inter-
Process Communication.
Hardware Controllers
Google Chromebooks, with the installed Google Chrome Operating System, come in a variety of
hardware with the top of the line Samsung Series 5 Chromebook having the Intel Celeron Processor
867, 4GBs DDR3 memory, 16GB SSD for storage, and Intel shared integrated. Graphics along with
other various hardware components.

The Google Chrome Operating System kernel is the Monolithic Linux-based kernel. Like all
Monolithic kernels the operating system is being run in kernel mode and also by itself in supervisor
mode. In addition, the services are all share a common location. An overview of the Linux-based
kernel shows it can be further dissected into five categories. The Process Scheduler, Memory
Manager, Virtual Filesystems, Network Interface, and Inter-Process Communication all make up the
Linux Kernel.
PROCESS MANAGEMENT
The Process Scheduler
The Process Scheduler’s purpose it to control process access to the CPU. Operating systems use a
variety of types of schedulers to do so. The Google Chrome Operating System uses the Completely
Fair Scheduler. This scheduler is designed to balance or maintain fairness, by splitting up processor
time to tasks. To do this the scheduler uses a virtual runtime to keep track of the length of time
provided to task at hand. This way the task that has been permitted the least amount of time to the
processor, becomes the task that needs the processor the most.
MEMORY MANAGEMENT
The Memory Manager
The Memory Manager, of The Google Chrome Operating System ’s, purpose is to control process
access to the hardware’s memory components. The Memory Manager is able to do so by using a
hardware memory management system which supports mapping to occur from the process memory
identifying code to the systems memory. This allows processes to all access main memory at the
same time.
The Virtual File System
The goal of the VFS is to provide a generic format of hardware data to other devices on the system.
The VFS of The Google Chrome Operating System provides an abstraction of most hardware
devices in the machine and puts the abstraction in a common file interface for that rest of the devices
on the machine can interpret. The Virtual File System also supports other file system formats that
are associated with other operating systems such as Windows.
The Network Interface

The Network Interface of the Google Chrome Operating System allows the Chrome OS to
communicate to other systems in a network. The Network Interface abstracts hardware devices and

network protocols for the user processes other systems on the kernel so they can access the network
without knowing what physical protocol or devices are actually being used.
Inter-process Communication
This is an essential subsystem of the Google Chrome Operating Systems. Inter-process
Communication inhibits process to process communication running on the same machine. This is
important if a process uses another process in order to function.
CPU Scheduling
The Google Chrome Operating System runs the Linux 3.4.6 kernel which utilizes the Completely
Fair Scheduler. The goal of the Completely Fair Scheduler is to ensure fairness. This is done by
allowing processes an equal share of the Central Processing Unit. For example, the process that has
had the least amount of time with the CPU needs the CPU the most. In order for the Completely Fair
Scheduler to maintain balance, the scheduler keeps track of the amount of time each process has had
with the CPU using a virtual runtime. The Completely Fair Scheduler uses a red black tree to sort by
time. The red black tree is ideal for the scheduler, for red black trees only allow the furthest node to
be one level lower. In addition, red black trees big O time is O (log n) allowing for fast operations.
The Completely Fair Scheduler also allows for group scheduling. Group scheduling ensures that in
situations where tasks spawn other tasks, each single task is ensured their own virtual runtime rather
than treating tasks uniformly.
Security
While the Google Chrome Operating System is by default more secure than most operating systems
due to its constant update on each boot it also utilizes Sandbox to maintain security. Sandbox is able
to provide security by only allowing programs to run that are not going to alter unauthorized areas of
the operating system, machine, or private information. The Sandbox was designed for user mode
only. This means that the user does not need to be a super user in order to use the Sandbox. The
Sandbox is configured into two separate processes. The first is the broker process. In Chrome OS the
broker is solely the browser process. The broker can be viewed as an administrator that dictates the
Sandboxes processes. The broker has a variety of jobs such as housing Sandbox policy engine
service, interception manager, and IPC service, creating target process, determine policy for all
target processes, and execute the policy allowed actions for the target process. The target process in
the Chrome OS is the renderers. The target projects job is to house all the data that is to be executed
in the Sandbox as well as the Sandboxes client-side architecture. Such as the IPC client, policy

engine

client, interceptions, and any data that goes in the Sandbox.
System Boot
On most operating systems, once powered on the firmware searches for components inside the
computer, or externally, and initializes them one at a time, followed by a splash screen that displays
the laptop maker. After the firmware finishes it will load the bootstrap loader which locates and
retrieves a program that will boot from the hard drive to intern load the kernel. The kernel searches
for all components once more and initializes them. Next another splash screen will display the
operating system whether it is Windows, Mac, Linux, etc. After all this the user is finally able to
login. Upon startup, all startup applications will then start further slowing down the system such as
antivirus software. Finally, the user is able to login (again) to the web browser. In Chrome OS the
boot process has been made much faster by eliminating all unnecessary procedures. Since the
Chromebook has been designed exclusively for Chrome OS the firmware does not have to search for
components, it already knows what is in it. Next it does not check to see if there is a CD, DVD, or
USB inserted in the machine thus eliminating more time. Initializing hardware is slow; therefore, it
has been moved from the firmware to the kernel which stops multiple devices from powering on
during startup. Furthermore, all splash screens have been eliminated as they are unnecessary. There
is no bootloader, therefore, we jump straight to the kernel. There are no startup applications other
than the browser, so no waiting for normal start up applications. Finally, since it already knows your
Google Account there is no need to login. By replacing the outdate HDD with a much faster SSD,
there are no moving parts, which eliminates the time wasted by waiting for a needle to move to the
correct location. In turn Google Chrome OS can often boot in under five seconds.
Event Handling
Device drivers that can be found in the kernel perform event handling as well as interrupts. Once the
kernel has been alerted, the application that is waiting for that particular event or interrupts receives
notification. The parts that are doing the event handling are not aware of any time constraints to
execute the procedure. While not an issue with event handling, it becomes an issue when interrupts
are involved. On a Chrome OS machine such as a Chromebook, interrupts are first priority. This can
cause problems when a task with first priority is cut off by another interrupt. Since the system does
not know for sure when this scenario can happen, there is often setbacks.
Cloud Storage
Chromebooks and Chrome boxes both come with 100GB of cloud storage that Google offers for
free as an incentive to sell these machines. The reason Google is able to offer their Samsung
version of

Chromebooks much cheaper than Samsung’s Windows PCs is because the demand for 500GB or
1TBhard drives has been eliminated. Most Chromebooks come with 16 GB’s of storage, the rest of
the user’s data is stored through cloud storage. Cloud storage is a network of online storage where
data can be saved using virtual storage in our case housed by Google. Data centers act as
warehouses where cloud data is stored. For cloud storage to work all that is needed is one server that
has access to the web. When a client decides to store data, a copy of the data instead of the data
itself, is sent over the
connection the server’s data center where it will be stored until the client sends the signal to retrieve
the data.
There are multiple advantages of cloud computing. Cloud Storage’s biggest advantage is it
eliminates the use for large HDD and SSD thus cutting cost in hardware. Next, if the client’s
computer were to crash, they would be able to then retrieve their data from the server’s data center.
Finally, many third-party Cloud Storage Companies allow up to a certain amount of storage for free
(2GBs standard). This is enough to backup basics such as pictures, music, and important documents.
Current Research
When first introduce the Google Chrome Operating System’s interface was a Chrome web window
allowing for no way to exit out of the window. Chrome OS’s most recent update was their Aura
Shell. Aura gives the advantage of a traditional desktop feel that is familiar with most Windows,
Mac, and Ubuntu users. Icons for applications can be found on the bottom which Google has named
“shelf”, which will feel very familiar to Window’s taskbar. In addition, the newest version of
chrome now allows for multiple windows rather than multiple tabs inside the Google Chrome and
Chrome boxes will also become cheaper in the near future due to a variety of factors. The first
reason is that companies such as HP, Dell, and Asus will soon be in on the action instead of
Samsung being the only producer. The competition while drive the price down in order to sell the
company’s product. Next prices on hardware will continue to go down due to the fact that
Chromebooks do not need the latest and greatest hardware to be proficient. As Intel continues to
release its 3rd and 4th generation i3, i5, i7 processors, the price will go down for their older Pentium
processors. In addition, Solid State Drives price per GB is dropping much faster than the Hard Disk
Drive ever has. Finally, Sergey Brin has said that Chrome OS and Android, Google’s highly
successful mobile operating system, will eventually combine to form one universal operating
system. Android dominates the mobile phone operating system market with nearly three out of every
four phones is an Android.
Market implications
When Google announced the Chrome browser in September 2008 it was viewed as a continuation of
the battle between Google and Microsoft ("the two giants of the digital revolution"). As of
December 2009, Microsoft dominates the usage share of desktop operating systems and the software
market in word processing and spreadsheet applications. The operating system dominance may be
challenged directly by Google Chrome OS, and the application dominance indirectly through a shift
to cloud computing. According to an analysis by PC World, Google Chrome OS represents the next
step in this battle. But Chrome OS engineering director Matthew Papakipos has noted that the two
operating systems will not fully overlap in functionality. Users should be aware that Chrome OS
hosted on a netbook is not intended as a substitute for Microsoft Windows running on a
conventional laptop, which has the computational power to run a resource-intensive program like
Photoshop.
In November 2009, Glyn Moody, writing for Linux Journal, predicted that Google's market model
for the Chrome OS will be to give the software and the netbook hardware that it will run on away for
free, as a means of expanding its advertising-based model. He said: "The unexpected success of
netbooks over the last two years shows there is a market for this new kind of computing; giving
away systems for free would take it to the next level. Then, gradually, that instant-on, secure,
secondary netbook might become the one you spend most time on, and Google's ad revenues would
climb even higher. "
Relationship to Android
The successive introductions of Android and Google Chrome OS, both open source, client-based
operating systems, have created some market confusion, especially with Android's growing success.
Microsoft CEO Steve Ballmer accused Google of not being able to make up their mind. [ Google has
downplayed this conflict, suggesting that the two operating systems address different markets,
mobile and personal computing, which remain distinct despite the growing convergence of the
devices. Co- founder Sergey Brin suggested that the two systems "will likely converge over time".
Motivation and background:

Google designed Chrome for people who live on the web — searching for information, checking
email, catching up on the news, shopping or just staying in touch with friends. However, the
operating systems that browsers run on were designed in an era where there was no web. So today,
Google's announcing a new project that's a natural extension of Google Chrome — the Google
Chrome Operating System. It's Google’s attempt to re-think what operating systems should be.

Computers need to get better. People want to get to their email instantly, without wasting time
waiting for their computers to boot and browsers to start up. They want their computers to always
run as fast

as when they first bought them. They want their data to be accessible to them wherever they are and
not have to worry about losing their computer or forgetting to back up files. Even more importantly,
they don't want to spend hours configuring their computers to work with every new piece of
hardware, or have to worry about constant software updates. And any time our users have a better
computing experience, Google benefits as well by having happier users who are more likely to
spend time on the Internet.
Related Work:
Google Chrome OS is a new project, separate from Android. Android was designed from the
beginning to work across a variety of devices from phones to set-top boxes to netbooks. Google
Chrome OS is being created for people who spend most of their time on the web, and is being
designed to power computers ranging from small netbooks to full-size desktop systems. While there
are areas where Google Chrome OS and Android overlap, Google believes choice will drive
innovation for the benefit of everyone, including Google.
Google Chrome OS is an open source, lightweight operating system that will initially be targeted at
netbooks. Later this year Google will open-source its code, and netbooks running Google Chrome
OS will be available for consumers in the second half of 2010. Because Google's already talking to
partners about the project, and it'll soon be working with the open source community, Google
wanted to share our vision now so everyone understands what we are trying to achieve.
Google has a lot of work to do, and Google’s definitely going to need a lot of help from the open
source community to accomplish this vision.

CHAPTERS THREE
ARCHITECTURE
Software Architecture:
Fig 3.1 Software architecture
High-level design
We'll look at each component, starting with the firmware.
4.1 Firmware
The firmware plays a key part to make booting the OS faster and more secure. To achieve this goal
we are removing unnecessary components and adding support for verifying each step in the boot
process. We are also adding support for system recovery into the firmware itself. We can avoid
the complexity that's in most PC firmware because we don't have to be backwards compatible
with a large amount of legacy hardware. For example, we don't have to probe for floppy drives.
Our firmware will implement the following functionality:
System recovery: The recovery firmware can re-install Chromium OS in the event that the
system has become corrupt or compromised.
Verified boot: Each time the system boots, Chromium OS verifies that the firmware, kernel,
and system image have not been tampered with or become corrupt. This process starts in the
firmware.
Fast boot: We have improved boot performance by removing a lot of complexity that is
normally found in PC firmware.

Fig 3.2 hardware and firmware
System-level and user-land software

From here we bring in the Linux kernel, drivers, and user-land daemons. Our kernel is mostly stock
except for a handful of patches that we pull in to improve boot performance. On the user-land side
of things we have streamlined the init process so that we're only running services that are critical.
All of the user-land services are managed by Upstart. By using Upstart we are able to start services
in parallel, re-spawn jobs that crash, and defer services to make boot faster.
Here's a quick list of things that we depend on:
D-Bus: The browser uses D-Bus to interact with the rest of the system. Examples of this include the
battery meter and network picker.
Connection Manager: Provides a common API for interacting with the network devices, provides a
DNS proxy, and manages network services for 3G, wireless, and ethernet.
WPA Supplicant: Used to connect to wireless networks.
Auto update: Our auto update daemon silently installs new system images.
Power Management: (ACPI on Intel) Handles power management events like closing the lid or
pushing the power button.
xscreensaver: Handles screen locking when the machine is idle.
Standard Linux services: NTP, syslog, and cron.
Chromium and the window manager

The window manager is responsible for handling the user's interaction with multiple client windows.
It does this in a manner similar to that of other X window managers, by controlling window
placement,

assigning the input focus, and exposing hotkeys that exist outside the scope of a single browser
window. Parts of the ICCCM (Inter-Client Communication Conventions Manual) and EWHM
(Extended Window Manager Hints) specifications are used for communication between clients and
the window anager where possible.
The window manager also uses the XComposite extension to redirect client windows to offscreen
pixmaps so that it can draw a final, composited image incorporating their contents itself. This lets
windows be transformed and blended together. The Clutter library is currently used to animate these
windows and to render them via OpenGL or OpenGL|ES.
Firmware Boot and Recovery
Firmware
1. Incomplete update: An update of the firmware is interrupted. This leaves the portion of the
firmware which was being updated in an unknown or corrupt state. For example, if the update is
interrupted after a firmware block is erased but before it is reprogrammed, that block is empty.
2. Attack: An attacker compromises the software and is able to reprogram the firmware. For
example, an exploit of an unpatched kernel vulnerability. In this case, both the main and backup
firmware may be compromised.
3. Corruption: The EEPROM holding the firmware becomes corrupted in the sectors containing
writable/updatable firmware.
Software
1. Incomplete update: An update of the software on the drive is interrupted. This leaves the rootfs
partition in an unknown state.
2. Attack: An attacker compromises the software and is able to rewrite the data on the drive (rootfs
or partition table).
3. Malicious user: A malicious user installs developer mode onto the device, leaving behind a
trojan, then returns the device.
4. Corruption: The drive becomes corrupted in the partition table or rootfs partition.
5. Crash: Device crashes on boot due to bad software. For example, the device is updated with the
wrong image. This prevents the normal auto update process from running.

Design decisions
Boot needs to start securely
In order to attempt a secure boot, the initial boot stub needs to perform a minimum level of
initialization to verify the next piece of boot code before handing off to that code.
To prevent accidental or intentional corruption of the known-good boot stub, this code must be in a
portion of memory which is not field-writable. Many EEPROM devices have an external pin (WP)
which can be pulled low to write protect the upper portion of the EEPROM. This has a number of
benefits:
Devices are writable at time of manufacture (as opposed to true ROMs, which are fixed at time of
ROM manufacture).
Devices can be made writable for firmware development by simple hardware modification.
Both readable and read-only ROM are provided by a single device. Simpler board design, fewer
parts, lower cost.
Any attacker who can open the case and modify the hardware to write to the protected upper portion
of ROM could also simply replace a true ROM with a reprogrammed part, so this isn't significantly
less secure than a true ROM.
On ARM platforms, the initial boot ROM may be in the same package as the processor. This is even
more secure compared to a separate EEPROM. Writable firmware should have a backup
To protect against a failed firmware update, the writable portion of the firmware (responsible for
doing the remainder of chipset and storage setup and then bootstrapping the kernel off the storage
device) should exist in two copies. In the event the first copy is corrupt, the device can boot
normally off the second copy. This is similar to the design for the file system, which has two copies
of the root partition.
Recovery firmware must be read-only

Recovery firmware must be able to take over the boot process if the boot stub determines that the
normal writable firmware is corrupt, or if the user manually boots the device into recovery mode.
To prevent the recovery firmware from being corrupted by a firmware update or a software-based
attack, it must be in the same read-only portion of the EEPROM as the boot stub.
Recovery firmware does not need to access the network
The recover process should not require firmware-level network access by the device being
recovered. The recovery procedure can involve a second computer, which is used to create recovery
media (for example, a USB drive or SD card). It is assumed that second computer has network

access. This simplifies the recovery process, since the recovery firmware only needs to bring up
enough of

the system to bootstrap a Linux image on local storage. That image can then take care of reflashing
the EEPROM and reimaging.
It is not necessary to implement a full network stack with WiFi configuration in the recovery
firmware to support PXE boot. PXE boot introduces a number of complications:
Need to initialize more hardware to bring up wireless, keyboard, etc.
Need to implement a full network stack.
Makes recovery an interactive process, including the user entering their SSID and WPA key, which
the user may not know.
Unlikely to work for public WiFi access points; these often redirect http access to a login screen,
navigation of which which would necessitate a full browser in the recovery firmware.
Unlikely to work for 3G, if that requires more complicated drivers or configuration.
All of these issues would need to be resolved, and the resulting firmware must be correct at the time
the device ships, because recovery mode firmware can't be updated in the field. It is unacceptable to
ship a mostly-working PXE solution, assuming that the user can fall back on a second computer in
the event PXE recovery fails. The only time the user would discover PXE recovery didn't work is
when the user is relying on it to repair their computer.
Recovery firmware should tell the user how to recover

If the recovery firmware finds a USB drive/SD card with a good recovery image on it, it should boot
it and use that to recover. The software in that recovery image will have its own user interface to
guide the user through recovery.
If the recovery firmware does not find a good recovery image, it needs to tell the user how to use a
second computer to build that recovery image.
The preferred way to do this is to initialize the screen and show recovery instructions to the user,
including a URL to go to in that second computer's web browser. Note that recovery instructions need to be
displayed in the correct language for the user.
It is desirable for the recovery instructions and/or recovery URL to include a code for the device
model. This allows the destination website to:
 Provide the proper recovery image for that device model.

 Describe the recovery procedure specific to that device model. For example, if the device has a SD
card but no USB port, the recovery procedure would indicate that a SD card is necessary, and would
not discuss the possibility of recovering using USB.
 Display graphics appropriate for the device model. For example, showing the location of the USB or
SD card port.
Users must be able to manually trigger recovery mode
If the writable firmware and/or rootfs have valid signatures but don't work (for example, the user
somehow managed to get an ARM kernel on an x86 device), the user needs to be able to force
recovery mode to run.
This can be done by having a physical reset button somewhere on the device. When this button is
pressed during power-on, the device goes straight to the recovery firmware without even looking at
the writable firmware or file system.
Some options for the recovery button:
 It could be a button attached to a GPIO on the main processor. In this case, the boot stub would
initialize the GPIO and read its state at boot time.
 It could be a button attached to a subprocessor such as the Embedded Controller (EC). In this case,
the boot stub would need to request the button state from the EC at boot time.
 It could be one of the keys on the keyboard, though this creates the undesirable possibility
of accidentally entering recovery mode.
o This is undesirable if the only interface to the keyboard is USB, because USB firmware is more
complex and the USB hardware interface can take a significant amount of time to initialize.
o Some devices use a subprocessor to read the keyboard. In this case, initiating recovery mode is
much like the previous option.
o The keyboard could bring out the press-state of one of its keys to a separate I/O line, which could be
attached to a GPIO on the processor or to a subprocessor.
Since the recoverability of Chromium OS is one of its key features, we seek to have a dedicated
"recovery mode" button.
Support developers / l33t users installing their own software
To provide a relatively trustable boot for the majority of users, we need to control all the read-only
firmware at the beginning of the boot process.
To support developers, at some point during the boot process, we need to hand off to code self-
signed by someone else.
The initial devices will allow handoff at the point the kernel is loaded and its embedded signature is

checked. This can produce one of three results:
 Trusted kernel: The kernel has a valid signature, and the signing key is known to the firmware. This
is the normal case for production devices.
 Developer kernel: The kernel has a valid signature, but the key used to sign the kernel is not known
to the firmware. This is the case when a developer builds and self-signs their own kernel.
 Corrupt kernel: The kernel fails its signature check.
Once the chain of trust departs from the standard Chromium OS boot chain, we need to indicate this
clearly to the user of the device. This prevents malicious attackers from giving users a modified
version of Chromium OS without the user knowing. We likely will need to show a warning screen
which includes the following elements:
 A warning that the standard image of Chromium OS is not running
 A means of reverting back to the standard Chromium OS image
 A means of allowing the user/developer to proceed down the "untrusted" path
It is desirable for the warning screen to have a timeout, so that Chromium OS devices with
developer images can be used in unattended applications (for example, as a media server). The
timeout should be sufficiently long that a user can read and respond to it - for example, at least 30
seconds.
Since language settings will not be available at this stage of the boot process, any messaging will
likely need to be internationalized and displayed in all possible la

CHAPTER FOUR
File System
Auto update Goals
The auto update system has the following goals:

 Updates are delta-compressed over the wire.
 Delta updates are quick to apply.
 Root file system is mounted read-only (another mount point is read/write for storing state).
 Device can automatically revert to previous installed version of the OS if the newly installed OS
fails to boot properly.
 Updates are automatic and silent.
 Updates should be small.
 System protects users from security exploits.
 System never requires more than one reboot for an update.
 There's a cap on how much space the root file system, previous version(s), downloaded updates, etc.
can take up.
 There's a clear division between the storage locations on the drive for system software and for user
data.
 The new update must be set bit-for-bit from the server, since we will be signing each physical block
on the system partition. (For more information, see the Verified Boot design document.)
Partitions
A drive currently contains up to four partitions:
 One partition for state resident on the drive (user's home directory/Chromium profile, logs,
etc.)—called the "stateful partition."
 An optional swap partitions.
 Two partitions for the root file system.
In the future, drives may be able to have more partitions, as needed. Because we can use extended
partitions, we aren't limited to four partitions.
Root file system
Only one of the two partitions designated for the root file system will be in use at a given time. The
other will be used for auto updating and for a fallback if the current partition fails to boot.
While a partition is in use as the boot partition, it's read-only until the next boot. Not even the auto
updater will edit the currently-booted root file system. We will mount the stateful partition read-

write

and use that for all state that needs to be stored locally.
During auto update, we will write to the other system partition. Only the updater (and apps running
as root) will have access to that partition.
The update processes
Open issue: How to efficiently deploy delta updates that result in a partition that's bit-for-bit what
we want?
Successful boot
The update process relies partly on the concept of a "successful boot." At any given point, we will
be able to say one of the following things:
This system booted up correctly.
 This system booted up incorrectly.

 The system is currently attempting to boot, so we don't know yet.
Open issue: For a boot to count as successful, does the user have to successfully log in? Does the
OS have to successfully ping the update server?
Once a system has booted successfully, we consider the other root partition to be available for
overwriting with an auto update.
Limiting the number of boot attempts
An updated partition can attempt to boot only a limited number of times; if it doesn't boot
successfully after a couple of attempts, then the system goes back to booting from the other
partition. The number of attempts is limited as follows:
When a partition has successfully been updated, it's assigned a remaining attempts value, probably
1 or 2. This value will be stored in the partition table next to the bootable flag (there are some
unused bits that the boot loader can use for its own purposes). The boot loader will examine all
partitions in the system; if it finds any partition that has a remaining attempts value > 0, it will
decrement remaining attempts and then attempt to boot from that partition. If the
Boot fails, then this process repeats.
If no partitions have a remaining attempts value > 0, the boot loader will boot from a partition
marked bootable, as a traditional boot loader would.
Open issue: What's the initial value for remaining attempts?
Boot Sequence

Fig 4.3 Boot sequence
Disk speed and battery life
Simple benchmarks indicate that dm-crypt can perform many operations at approximately the same
speed and power cost as the system does without encryption. It's when sustained reads and writes
occur that more and more CPU is used. A test with a heavy, sustained write resulted in the same
battery discharge rate as the heavy writing used without encryption, but the encrypted large write
took about twice as long to complete.
In most use cases, disk encryption isn't noticeable. If AES acceleration reaches additional
processors, then the impact will be even lower. .
Directory structure
All metadata for this feature will live under the /home/. shadow directory. Each user will have a
subdirectory with a name based on the user name hash. That directory will contain all data related to
that user's image on the machine.For example:
/home/.shadow/da39a3ee5e6b4b0d3255bfef95601890afd80709/image
/home/.shadow/da39a3ee5e6b4b0d3255bfef95601890afd80709/salt.0
/home/.shadow/da39a3ee5e6b4b0d3255bfef95601890afd80709/key.0

CHAPTER FIVE
SECUITY OVERVIEW
Protecting Cached User Data
Problem: Multiple users, portable devices, locally stored data
Chromium OS devices should provide privacy protection for user data stored on the local disk. In
particular, some subset of a user's email, pictures, and even HTTP cookies will be stored on the local
drive to enhance the online experience and ensure Chromium OS devices are useful even when an
Internet connection isn't available. Without this protection, anyone who has physical access to the
Chromium OS device will be able to access any data cached on it.
Normally, data stored in the cloud is protected by privacy-guarding mechanisms provided by the
servers that host it. When data is pulled out of the cloud, it moves outside of the reach of those
server- provided protections. Even though this is the case today with most computers, there are two
areas that make this even more important to Chromium OS devices:
 With a Chromium OS device, users shouldn't have to worry about whether other users of the same
device can see their cached data. For example, if my friend wants to log in to my device to check her
mail, it's not a big deal. She won't be able to access my data, and even though she used my device, I
won't be able to access her data.
 Chromium OS is designed for portable devices. The risk with very portable devices is that they are
easy to misplace or leave behind. We don't want the person who finds a device to instantly have
access to all of the owner's websites, emails, pictures, and so on.
Solution: Encryption
Since Chromium OS is built on Linux, we can leverage existing solutions for encrypting the user's
data at the underlying operating system level. Given the available implementation choices, many
possible approaches were considered (see Appendix D for details). Of those approaches, we chose a
solution that provides file system-level encryption of home directories for each user on a device.
Encrypting each user's home directory means that all of the data stored by the Chromium-based
browser will be encrypted by default. In addition, data created and maintained by plugins, like
Adobe Flash, as well as any data stored by HTML5-enabled web apps will be transparently
encrypted without developers or users needing to take any special action.
Reclaiming lost space

Reclaiming space lost to file system fragmentation has always been a challenge with the sparse file
implementations on Linux. There have been numerous discussions about supporting device calls
that will tell the kernel, and then the backing device, to release unused blocks. At present, no

agreed upon

solution has been implemented in a way that meets our needs. The only other option in use is
crawling the file system metadata manually and writing zeroes to any freed blocks. This is not only
costly in I/O but also probably detrimental to SSDs.
This is another area in which ext4 has a chance to shine. ext4 explicitly supports file system
defragmentation and even supports (online) defragmentation of mounted file systems. In addition, it
is designed to minimize fragmentation where possible during file allocation. What does this mean
for sparse files?
If a file system image is kept as defragmented as possible, the required data footprint for the image
should be minimal. To that end, we will keep an event-triggered daemon running that checks for
fragmentation in the background while the user is creating or deleting data. If the file system has
started to become fragmented enough to benefit from defragmentation, it will perform an online
defragmentation. This will keep the file system footprint minimized. On logout, the file system will
be resized to this minimal size, the file truncated, and then re-extended, sparsely. An online resize
will occur at next login and the wasted data will be recovered.
While this sounds nice and tidy, there are a number of implementation details that will need to be
dealt with. The fragmentation monitoring and defragmentation tasks may need to occur only when
the device is connected to an AC adapter. The same goes for resizing on logout. It also won't make
sense to waste any time defragmenting or reclaiming lost space if a device is single user. The space
in the image will always be reusable by the same user.
The last issue that will need attention is ensuring that minimal resizing is both reliable and quick.
Currently, resizing downward requires a forced file system check. If it is practical and possible to
avoid it or speed it up, re-sparsifying the user images will be a lightweight and effective process.
We have made a concerted effort to provide users of Chromium OS-based devices with a system
that is both practically secure and easy to use. To do so, we've followed a set of four guiding
principles: The perfect is the enemy of the good.
 Deploy defenses in depth.
 Make devices secure by default.
 Don't scapegoat our users.
In the rest of this document, we first explain these principles and discuss some expected use
cases for Chromium OS devices. We then give a high-level overview of the threat model against
which we will endeavor to protect our users, while still enabling them to make full use of their cloud
device.

OS hardening
The lowest level of our security strategy involves a combination of OS-level protection
mechanisms and exploit mitigation techniques. This combination limits our attack surface, reduces
the the likelihood of successful attack, and reduces the usefulness of successful user-level exploits.
These protections aid in defending against both opportunistic and dedicated adversaries. The
approach designed relies on a number of independent techniques:
 Process sandboxing
 Mandatory access control implementation that limits resource, process, and kernel interactions
 Control group device filtering and resource abuse constraint
 Chrooting and process namespacing for reducing resource and cross-process attack surfaces
 Media device interposition to reduce direct kernel interface access from Chromium browser
and plugin processes
 Toolchain hardening to limit exploit reliability and success
 NX, ASLR, stack cookies, etc
 Kernel hardening and configuration paring
 Additional file system restrictions
 Read-only root partition
 tmpfs-based /tmp
 User home directories that can't have executables, privileged executables, or device nodes
 Longer term, additional system enhancements will be pursued, like driver sandboxing
Detailed discussion can be found in the System Hardening design document.
Making the browser more modular
The more modular the browser is, the easier it is for the Chromium OS to separate
functionality and to sandbox different processes. Such increased modularity would also drive
more efficient IPC within Chromium. We welcome input from the community here, both in
terms of ideas and in code. Potential areas for future work include:
 Plugins
o All plugins should run as independent processes. We can then apply OS-level
sandboxing techniques to limit their abilities. Approved plugins could even have Mandatory
Access Control (MAC) policies generated and ready for use.
 Standalone network stack
o Chromium browsers already sandbox media and HTML parsers.

o If the HTTP and SSL stacks were isolated in independent processes, robustness issues
with HTTP parsing or other behavior could be isolated. In particular, if all SSL traffic used one
process while all plaintext traffic used another, we would have some protection from
unauthenticated attacks leading to full information compromise. This can even be beneficial for
cookie isolation, as the HTTP-only stack should never get access to cookies marked "secure." It
would even be possible to run two SSL/HTTP network stacks—one for known domains based
on a large whitelist and one for unknown domains. Alternately, it could be separated based on
whether a certificate exception is required to finalize the connection.
 Per-domain local storage
o If it were possible to isolate renderer access per domain, then access to local storage
services could similarly by isolated—at a process level. This would mean that a compromise of
a renderer that escapes the sandbox would still not be guaranteed access to the other stored data
unless the escape vector were a kernel-level exploit.
Web app security
As we enable web applications to provide richer functionality for users, we are increasing the
value of web-based exploits, whether the attacker tricks the browser into giving up extra access
or the user into giving up extra access. We are working on multiple fronts to design a system that
allows Chromium OS devices to manage access to new APIs in a unified manner, providing the
user visibility into the behavior of web applications where appropriate and an intuitive way to
manage permissions granted to different applications where necessary.
 User experience
o The user experience should be orthogonal to the policy enforcement mechanism inside the
Chromium browser and, ideally, work the same for HTML5 APIs and Google Chrome
Extensions.
 HTML5/Open Web Platform APIs and Google Chrome Extensions
o We're hopeful that we can unify the policy enforcement mechanisms/user preference storage
mechanisms across all of the above.
 Plugins
o We are developing a multi-tiered sandboxing strategy, leveraging existing Chromium browser
sandboxing technology and some of the work we discuss in our System Hardening design
document.
o Long term, we will work with other browser vendors to make plugins more easily sandboxed.

o Full-screen mode in some plugins could allow an attacker to mock out the entire user experience
of a Chromium OS device. We are investigating a variety of mitigation strategies in this space.
As HTML5 features like persistent workers move through the standards process, we must ensure
that we watch for functionality creeping in that can poke holes in our security model and take
care to handle it appropriately.
Phishing, XSS, and other web vulnerabilities
Phishing, XSS, and other web-based exploits are no more of an issue for Chromium OS systems
than they are for Chromium browsers on other platforms. The only JavaScript APIs used in web
applications on Chromium OS devices will be the same HTML5 and Open Web Platform APIs
that are being deployed in Chromium browsers everywhere. As the browser goes, so will we.
Secure auto update
Attacks against the auto update process are likely to be executed by a dedicated adversary who
would subvert networking infrastructure to inject a fake auto update with malicious code inside
it. That said, a well-supported opportunistic adversary could attempt to subvert the update
process for many users simultaneously, so we should address this possibility here. (For more on
this subject, also see the File System/Auto update design document.)
 Signed updates are downloaded over SSL.
 Version numbers of updates can't go backwards.
 The integrity of each update is verified on subsequent boot, using our Verified Boot process,
described below.
Verified boot
Verified boot provides a means of getting cryptographic assurances that the Linux kernel, non-
volatile system memory, and the partition table are untampered with when the system starts
up. This approach is not "trusted boot" as it does not depend on a TPM device or other
specialized processor features. Instead, a chain of trust is created using custom read-only
firmware that performs integrity checking on a writable firmware. The verified code in the
writable firmware then verifies the next component in the boot path, and so on. This approach
allows for more flexibility than traditional trusted boot systems and avoids taking ownership
away from the user. The design is broken down into two stages:
 Firmware-based verification
(for details, see the Firmware Boot and Recovery design document)
o Read-only firmware checks writable firmware with a permanently stored key.

o Writable firmware then checks any other non-volatile memory as well as the bootloader and
kernel.
o If verification fails, the user can either bypass checking or boot to a safe recovery mode.
 Kernel-based verification
(for details, see the Verified Boot design document)
o This approach extends authenticity and integrity guarantees to files and metadata on the root file
system.
o All access to the root file system device traverses a transparent layer which ensure data block
integrity.
o Block integrity is determined using cryptographic hashes stored after the root file system on the
system partition.
o All verification is done on-the-fly to avoid delaying system startup.
o The implementation is not tied to the firmware-based verification and may be compatible with
any trusted kernel.
When combined, the two verification systems will perform as follows:
 Detects changes at boot-time
o Files, or read-write firmware, changed by an opportunistic attacker with a bootable USB drive
will be caught on reboot.
o Changes performed by a successful runtime attack will also be detected on next reboot.
 Provides a secure recovery path so that new installs are safe from past attacks.
 Doesn't protect against
o Dedicated attackers replacing the firmware.
o Run-time attacks: Only code loaded from the file system is verified. Running code is not.
o Persistent attacks run by a compromised Chromium browser: It's not possible to verify the
browser's configuration as safe using this technique.
It's important to note that at no point is the system restricted to code from the Chromium project;
however, if Google Chrome OS is used, additional hardware-supported integrity guarantees can
be made.
Rendering pawned devices useless
We do not intend to brick devices that we believe to be hacked. If we can reliably detect this
state on the client, we should just initiate an update and reboot. We could try to leverage the
abuse detection and mitigation mechanisms in the Google services that people are using

from their

Chromium OS devices, but it seems more scalable to allow each service to continue handling
these problems on its own.
Mitigating device theft

A stolen device is likely to have a higher value to a dedicated adversary than to an opportunistic
adversary. An opportunistic adversary is more likely to reset the device for resale, or try to log in to
use the device for himself.
The challenges here are myriad:
 We want to protect user data while also enabling users to opt-in to auto-login.
 We want to protect user data while also allowing users to share the device.
 We especially want to protect user credentials without giving up offline login, auto-login, and device
sharing.
 Disk encryption can have real impact on battery life and performance speed.
 The attacker can remove the hard drive to circumvent OS-level protections.
 The attacker can boot the device from a USB device.

CHAPTER SIX
DATA PROTECTION
Users shouldn't need to worry about the privacy of their data if they forget their device in a coffee
shop or share it with their family members. The easiest way to protect the data from opportunistic
attackers is to ensure that it is unreadable except when it is in use by its owner.
The Protecting Cached User Data design document provides details on data protection. Key
requirements for protecting cached user data (at rest) are as follows:
 Each user has his own encrypted store.
 All user data stored by the operating system, browser, and any plugins are encrypted.
 Users cannot access each other's data on a shared device.
 The system does not protect against attacks while a user is logged in.
 The system will attempt to protect against memory extraction (cold boot) attacks when additional
hardware support arrives.
 The system does not protect against root file system tampering by a dedicated attacker (verified
boot helps there).
Account management
Preventing the adversary from logging in to the system closes one easy pathway to getting the
machine to execute code on his behalf. That said, many want this device to be just as sharable as a
Google Doc. How can we balance these questions, as well as take into account certain practical
concerns? These issues are discussed at length in the User Accounts and Management design
document, with some highlights below.
 What are the practical concerns?
o Whose wifi settings do you use? Jane's settings on Bob's device in Bob's house don't work.
o But using Bob's settings no matter where the device is doesn't work either.
o And if Bob's device is set up to use his enterprise's wifi, then it's dangerous if someone steals
it!
 "The owner"
o Each device has one and only one owner.
o User preferences are distinct from system settings.
o System settings, like wifi, follow the owner of a device.
 Whitelisting
o The owner can whitelist other users, who can then log in.
o The user experience for this feature should require only a few clicks or keystrokes.
 Promiscuous mode
o The owner can opt in to a mode where anyone with a Google account can log in.
 Incognito mode
o Users can initiate a completely stateless session, which does not sync or cache data.

o All system settings would be kept out of this session, including networking config.
Biometrics, smart cards, and Bluetooth
We expect to keep an eye on biometric authentication technologies as they continue to become
cheaper and more reliable, but at this time we believe that the cost/reliability tradeoff is not where it
needs to be for our target users. We expect these devices to be covered in our users' fingerprints, so
a low-cost fingerprint scanner could actually increase the likelihood of compromise. We were able
to break into one device that used facial recognition authentication software just by holding it up to
the user's photo. Bluetooth adds a whole new software stack to our login/screenlocker code that
could potentially be buggy, and the security of the pairing protocol has been criticized in the past.
Smart cards and USB crypto tokens are an interesting technology, but we don't want our users to
have to keep track of a physically distinct item just to use their device.
Login
For design details, see the Login design document.
At a high level, here is how Chromium OS devices authenticate users:
1. Try to reach Google Accounts online.
2. If the service can't be reached, check an offline cache of user->password hash mappings.
3. For every successful online login, cache a mapping between the user and a salted hash of
his password.
There are a number of important convenience features around authentication that we must provide
for users, and some consequences of integrating with Google Accounts we must deal with. These
all have security consequences, and we discuss these (and potential mitigation) here. Additionally,
we are currently working through the various tradeoffs of supporting non-Google OpenID
providers as an authentication backend.
Auto-login
When a user turns on auto-login, he is asserting that he wishes this device to be trusted as though it
has his credentials at all times; however, we don't want to store actual Google Account credentials
on the device—doing so would expose them to offline attack unnecessarily. We also don't want to
rely on an expiring cookie; auto-login would "only work sometimes," which is a poor user
experience. We would like to store a revokable credential on the device, one that can be
exchanged on-demand for cookies that will log the user in to all of his Google services. We're
considering using an OAuth token for this purpose.
For third-party sites, we would like to provide credential generation and synced, cloud-based
storage.
CHAPTER SEVEN
STRENGTHS AND WEAKNESSES
Strengths of Chrome OS
 Chrome OS will run on x86 and ARM chips. Google says it’s working with several hardware
manufacturers to deliver netbooks running Chrome OS in the second half of 2010.
 Along with the mobile phone market, the netbook market is growing rapidly, unlike the
desktop PC market
 Chrome OS will include a variety of cloud-based services
to make life easier for users, including automatic backups and software updates
 The Chrome OS may also be an attempt to capitalize on emerging markets outside the U.S,
where desktop computers and laptops remain prohibitively expensive for many people.
 Speed, simplicity, and security are the key aspects of the OS, Google says, maintaining that it
will start up and get you onto the Web in a matter of seconds and will have a minimal user
interface.
Weaknesses of Chrome OS
 Netbooks are usually secondary computers, bought by people who already
have desktops or notebooks; in that case, a smartphone is a better, more useful choice.
 Chrome OS has another problem, which sets it apart from other netbooks: It only runs
browser- based apps.
 “Browsers don’t yet do everything, and there are two decades of Windows applications that
have
been written, performing functions that can’t yet be replicated in a browser
Future Scope
First, they need to open Chrome OS to light weight, third-party apps—not desktop apps, but
rather apps that are purpose-built to run on low-powered devices. Also, they need to change
the form factor. Chrome OS devices should not be traditional, clamshell laptops; they need to
be tablets or some other form factor designed for on-the-go use. Otherwise, by the time
vendors come out with Chrome OS devices late next year, the market will already have moved
on.
Chrome OS developers have stated that Chrome OS will be stored only on solid state devices
and not on traditional hard disks. But most people still prefer hard disks than solid state
devices. So, they need to sort out this problem so that Chrome OS can be stored even on
traditional Hard Disks.

CONCLUSION
As the epic operating-system battle continues between OS X and Windows, a lesser-known
contender is slowly gaining ground. Google's Chrome OS is built on the assumption that users
spend a majority of their computer time online, and that Internet connectivity is becoming
ubiquitous. Since its release in 2009, Chrome is already on version 25, which brings with it a
better Flash engine, multi monitor support and improved Bluetooth connectivity. Can a Chrome
book successfully replace a notebook running OS X or Windows? Or does Google's Web-based
operating system still lag behind the competition, however Chrome will pave the way for more
operating systems with the cloud computing technology
REFERENCE
1. www.chromium.org/chromium-os
2. www.wikipedia.com
3. www.inforamationweeklyanalytics.com
4. Digit Magazine Jan 2010 issue

5. http://asia.cnet.com/the-limitations-of-google-chrome-os-62060383.htm
6. http://www.laptopmag.com/reviews/software/chromeos-version-25.aspx
7. http://www.forbes.com/sites/eliseackerman/2012/03/02/security-expert- warns-of-risks-in-
googles-chrome-os-and-apples-icloud/
8. http://www.fastcompany.com/1306198/why-googles-chrome-os-not-your- future
9. http://gizmodo.com/5408504/everything-you-need-to-know-about-chrome- os
10. http://www.eweek.com/cloud/google-issues-new-updates-for-chrome-os/
11. http://en.wikipedia.org/wiki/Chromium_OS
12. Pichai, Sundar (2009-07-07). "Introducing the Google Chrome OS". Official Google Blog.
Google, Inc.
http://googleblog.blogspot.com/2009/07/introducing-google-chrome-os.html
13. "The Chromium Projects: User Experience".
Google.http://www.chromium.org/chromium-os/user-experience
14. Chrome OS – Wikipedia, the free Encyclopedia http://en.wikipedia.org/wiki/ChromeOS
15. Netbook - Wikipedia, the free Encyclopedia http://en.wikipedia.org/wiki/Netbook
16. Cloud Computing - Wikipedia, the free Encyclopedia http://en.wikipedia.org/wiki/Cloud
Computing
17. Ten things to know about Google -http://www.techradar.com/news/software/operating-
systems/10-things-to-know-about-google-chrome-os-614370?artc_pg=1
18. Chrome OS Strives to Replace Desktop Culture
http://www.pcworld.com/businesscenter/blogs/network.html

Chrome Operating System

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chrome Operating System

Uploaded by

Copyright:

Available Formats

DIPLOMA IN TECHNICAL TEACHER EDUCATION

DEPARTMENT OF COMPUTER STUDIES

SYSTEM TASK: TERM

KARL IAN KIPRUTO

(karlkibet@gmail.com , karlkibet@yahoo.com , karlkibet@hotmail.com )

ii | P a g e OS TERM PAPER BY KARL IAN karlkibet@gmail.com

iii | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

OS: operating system

iv | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

1|Page OS TERM PAPER BY KARL IAN karlkibet@gmail.co

2|Page OS TERM PAPER BY KARL IAN karlkibet@gmail.co

Difference between Google Chrome OS and Chromium OS

What is Cloud Computing?

3|Page OS TERM PAPER BY KARL IAN karlkibet@gmail.co

4|Page OS TERM PAPER BY KARL IAN karlkibet@gmail.co

5|Page OS TERM PAPER BY KARL IAN karlkibet@gmail.co

6|Page OS TERM PAPER BY KARL IAN karlkibet@gmail.co

7|Page OS TERM PAPER BY KARL IAN karlkibet@gmail.co

8|Page OS TERM PAPER BY KARL IAN karlkibet@gmail.co

9|Page OS TERM PAPER BY KARL IAN karlkibet@gmail.co

Design Goals and Direction

11 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

12 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

13 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

14 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

15 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

File System Manipulation

16 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

The Network Interface

17 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

18 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

19 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

21 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

Motivation and background:

24 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

25 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

26 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

Fig 3.1 Software architecture

27 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

System-level and user-land software

WPA Supplicant: Used to connect to wireless networks.

xscreensaver: Handles screen locking when the machine is idle.

Standard Linux services: NTP, syslog, and cron.

Chromium and the window manager

29 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

Firmware Boot and Recovery

30 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

Recovery firmware must be read-only

31 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

32 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

Recovery firmware should tell the user how to recover

 Provide the proper recovery image for that device model.

33 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

34 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

35 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

The auto update system has the following goals:

37 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

38 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

 This system booted up incorrectly.

39 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

Disk speed and battery life

40 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co

Reclaiming lost space

41 | P a g OS TERM PAPER BY KARL IAN karlkibet@gmail.co