related.tex

\section{Prior and Future Work}

Embedded systems have historically had highly fragmented application domains,
each with a vertically integrated set of software and hardware
% that
% applications can customize as needed. However, until now, a common
% assumption in almost all embedded systems is
that a single group of developers
is responsible for.
%all of the code running on a device.
This complete oversight has typically meant
% They might borrow
% or use libraries or operating systems from elsewhere, but that code is
% completely under their control to modify and inspect as needed. Making
% this assumption means
that embedded operating systems have
minimal or no system security to protect themselves from malicious code
or applications.

One extreme example of this approach is TinyOS~\cite{tinyos}, which makes no
distinction between application and operating system code. Application
code specifies which abstractions and services it needs from the
operating system, and the compilation toolchain uses this information
to build an application-specific version of the OS that is compiled
and directly linked with application code.
Even with the threading library, TOSThreads~\cite{tosthreads}, and
dynamically linked applications, the
% Later
% versions of TinyOS included a threading library with which one could
% dynamically load and link applications~\cite{tosthreads}. These
% threads, however, operate under the assumption that the
application
developer and the system maintainer are assumed to be the same person
and applications
% : there are no
% security checks and since there is no memory protection applications
have unlimited access to the entire system.
The Contiki~\cite{contiki} operating system is another microcontroller-based
operating system
with extensive networking support. Security in Contiki is limited to
link-layer encryption and integrity and the OS can run only a single
application at once. SOS~\cite{han05sos}
provides dynamically loadable applications  and drivers on top of a
core kernel but provides no isolation or protection, therefore requiring 
both be trusted completely.

% . It has led TCP/IP integration with embedded systems
% through libraries such as the $\mu$IP stack and a fully
% certified IPv6 stack contributed by Cisco in 2008~\cite{contiki}.
%% again this is not true contiki supports dynically loaded code.

FreeRTOS~\cite{freertos} is an open-source commercial operating system intended to
support a wide range of applications on many different processors. It
is used in applications from the Nest Protect to smart meters to
thermal monitoring systems. FreeRTOS supports network security
through TLS~\cite{tls} and DTLS~\cite{dtls}, but operates under the
assumption that all code is trusted. For example, any task in the system
can spawn a task that runs in privileged mode and arbitrarily modify
% http://www.freertos.org/a00125.html
% http://sourceforge.net/p/freertos/discussion/382005/thread/7b135e95
the system~\cite{rtos-tasks,rtos-sec}.

Recent paravirtualization-based systems such as Dune~\cite{dune:osdi2012},
 Arrakis~\cite{arrakis:osdi2014}, and IX~\cite{ix:osdi2014}, have explored how hardware can
be directly exposed to applications for high-performance or greater
flexibility. These approaches all depend on the hardware virtualization (e.g.,
NICs, page tables). In contrast, embedded
systems have no virtualization. \name applications do not access a virtualized
SPI bus, they can gain direct access to hardware registers with no subsequent
OS or hardware arbitration.

Emerging embedded applications and platforms require new abstractions and
services from their operating systems. Simultaneously, new embedded processors
provide new mechanisms that are similar to, but distinct from modern and
earlier CPUs. This combination of application pull and technology push
creates many interesting problems in operating system design. As pervasive
computing, ubiquitous computing, sensor networks and the Internet of Things
all gain momentum, solutions to these problems will be increasingly 
important. We have presented one initial design for such an operating system,
called \name, which combines hardware memory protection with a modern
safe systems language to enable novel capabilities that meet the needs
of these emerging domains.