intro.tex

\section{Introduction}

As networking became an integral part of computing through the Internet and
world wide web, system security grew in importance from a niche interest of the
military into a core requirement for operating systems. While far from perfect,
today's general purpose operating systems support firewalls, NATs, encrypted
networking, no-execute bits, randomized memory allocation, signed packages, and a
host of other security features. With the growth in networked embedded
devices, it is time for embedded operating systems to follow suit.

Today, we see the emergence of ``intelligent'' \textit{things} that integrate
computing with physical devices.
% Smart watches such as the Pebble~\cite{pebble}
% provide a clock application and a limited set of applets.
% Smart light bulbs such
% as the Phillips Hue~\cite{hue} support simple functions---turn on, turn blue,
% glow brighter---and personal fitness trackers like Fitbit~\cite{fitbit} and
% UP~\cite{jawboneup} measure our steps, heart rate and sleep
% patterns.
Smart pill bottles such as AdhereTech's~\cite{adheretech} monitor our
medications and remind us of missed doses and wearable personal fitness trackers
like Fitbit~\cite{fitbit} and UP~\cite{jawboneup} measure our steps and sleep
patterns. But these devices are siloed: Fitbit cannot load a ``pill app'' that
vibrates when it is time to take today's medication.
As embedded systems grow from narrow applications into a more general
purpose computing platforms, there will be a need to dynamically load
applications and share hardware across multiple applications. In fact, this
trend is already underway: the Pebble watch~\cite{pebble}, for example, supports loading
executable code that can use the built-in sensors and display as well as
communicate with apps on a connected mobile phone.

%on and off, brighter and dimmer---,

Traditionally, embedded systems have been single-purpose, single-application
devices. A developer compiled a monolithic application image which incorporated
the OS and gave the application full access to underlying hardware.
The software was co-designed with hardware---i.e. by the same
people---and this paradigm was what the
underlying microcontrollers could support.
Without virtual memory or segmentation features
% Microcontroller families such as the MSP430 and Atmega were simple and
% lacked features of general-purpose processors such as virtual
% memory or segmentation. As a result,
embedded ``operating systems'' have no
security mechanisms and applications must be trusted completely. Even designs
which separate kernel and application code~\cite{han05sos,contiki,freertos}
require trusted applications.

However, a new generation of microcontrollers has emerged recently.
These processors, based on the ARM Cortex-M architecture, sit in a middle ground
between full-fledged CPUs and older microcontrollers. Like some mid-1980s processors,
they have a 32-bit address space, memory protection, and run at tens of MHz.
Like microcontrollers, they have tens to a few hundred KB of RAM, provide many
peripherals and bus interconnects (SPI, I2C, one-wire, UART/USART, etc.) and
have sub-\uA sleep currents, allowing them to operate on a battery for
months or years. The Atmel SAM4L~\cite{sam4l}, for example, is a
microcontroller with a Cortex-M4 processor (40~MHz, 64~KB RAM, 512~KB flash), a
plethora of peripherals (4 USARTs, 2 SPIs, 6 timers, native AES and a random number
generator) and has a sleep current as low as $0.9$~\uA.

Most importantly to an operating system, this new generation of microcontrollers includes
memory protection.
This can protect kernel memory, memory-mapped I/O, and
application memory from misbehaving applications. However,
isolation and safety is only as good as the kernel itself. As numerous recent
results show, OS kernels contain scores of memory access bugs that applications
can exploit to crash a system or gain unauthorized
access~\cite{kint:osdi2012,linuxvulns:apsys11}. By writing the OS kernel in a
type-safe, memory-safe language with strong semantics, we can eliminate whole
classes of vulnerabilities. The relative simplicity of Cortex-M processors and
embedded operating system APIs means that writing such a kernel is a
manageable task.  This makes an embedded OS especially well suited for
research in secure operating systems design.
% still open to easy extension and evolution.

It is time for embedded operating systems to evolve! In this paper, we argue
that an embedded operating system should be more than a hardware API.
It should enable and encourage
multiple concurrent, isolated applications, provide  hardware abstractions
as well as low-level hardware access, and offer critical services to Internet
of Things applications. We discuss three protection
mechanisms that operating systems should utilize to achieve these goals---language level isolation, software mediated hardware protection, and
multiple isolated processors.

%(alevy): I don't think we need this in the intro.
%As a concrete example of what such an operating
%system might look like, we present \name, a new operating system that combines
%hardware-based memory protection and language-based safety to provide a secure,
%robust platform for embedded applications.

% Sergio's note: This isn't particularly difficult since we've already discussed
% that the kernel and applications will be isolated by hardware. The language
% the applications are written in is irrelevant when this is the case.
%
% The principal challenge that arises is safely and correctly
% integrating untrusted application code in C with a type-safe kernel,
% particularly in how data passes between them and how the OS manages its memory
% layout.