protection.tex

\section{Protection \emph{is} a New Primitive}
\label{protection}

% pp 33--34, ch 1, sec 4:

%
This section examines recent advances and trends in embedded hardware and
programming languages that enable novel protection primitives in constrained
systems.

While traditional operating systems handle independently developed applications,
these OSes cannot simply be applied to the embedded domain. They assume virtual memory
for protection and isolation and are not designed to take advantage of memory protection subsystems
present in embedded hardware. They trust that drivers are written correctly,
granting them full access to kernel structures and memory, and fail when driver bugs
are present. Lastly, they are designed for cooperative cores with shared memory,
rather than physically isolated microcontrollers with private memories.


\subsection{Hardware Advances and Trends}

New embedded system platforms will be built on the Cortex-M series of microcontrollers.
While ARM's A-series is substantially more capable and is used in wall-powered
devices such as the HummingBoard~\cite{hummingboard} and BeagleBone Black~\cite{bbb},
its significant power draw (over 1~W in active mode) make it infeasible for
low-power, battery operated devices.
In contrast, Cortex-M series microcontrollers have power draws conducive to
low-power operation while adding hardware features that enable protection.


% Modern ARM devices come in three flavors: the powerful A-series
% microprocessors, the real-time R-series, and the efficient M-series
% microcontrollers.
% \hl{XXX: Why M over A}

{\bf Memory Protection Units.}
ARM's Cortex-M is a microcontroller design---a System-on-Chip with tightly
integrated memory---and does not (nor will it likely ever) integrate enough
memory to merit a Memory Management Unit (MMU). Instead, the Cortex-M series
includes a Memory Protection Unit (MPU), a lightweight, efficient subsystem
that provides the memory protection features similar to those found in an MMU
(e.g. it will trap illegal memory accesses such as writing to read-only memory)
but without address translation and at a much finer granularity.
With OS support an MPU can enable isolated applications, shared libraries, and
even possible relocation of running code.
% Pat: I'm 90% sure of how to do relocation with PIC, but I need to think about it more
MPUs are much more fine-grained than typical virtual memory. MPUs are able to
address regions as small a 32~bytes, whereas MMUs typically use at least 4~KB
pages. Moreover, MPUs support regions of any size that is a power of two larger
than 32 bytes (27 sizes in practice)~\cite{cortexm4-ug:ch4.5}, whereas MMUs
support a limited number of page sizes.\footnote{The Itanium architecture
supports eight page sizes, while x86 and ARMv7 both only support three.}
MPUs do not, however, perform any translation, so mechanisms such as swap and
dynamic page allocation may not be feasible.

{\bf Multi-Processor Platforms.}
Modern embedded platforms increasingly include multiple microcontrollers. For
example, the Nest Protect~\cite{nest-protect} includes a main Cortex-M4 application controller, a
secondary Cortex-M0+ peripheral processor, and an EM357 802.15.4 radio SoC with
an onboard Cortex-M3~\cite{nestprotect-teardown}. Adding additional
microcontrollers can allow offloading timing-critical communication
functionality or running certain computations on a microcontroller with a
different energy profile. Multiple processors provide an opportunity for the
strictest isolation, stochastic and deterministic real-time schedules, and
computation offloading.
Existing operating systems have not needed to provide abstractions for multiple
microcontrollers what these abstractions should be is an open question.
% It is less clear, however, how to abstract system-specific hardware for general
% applications and is an open question in the design of a new operating system.


% ARM TrustZone is also functionally like having a separate core, or at least
% that's the abstraction it tries to provide. Only available on Cortex-A's
% though

% Could also be interesting to talk about crypto co-processors here



%% OLD TEXT: impl-heavy
% \name leverages multiprocessor environments to provide protection where
% language-level and memory isolation are insufficient. In a multi-application
% environment, time-sensitive applications (e.g. that must process requests
% within a single radio scheduling quantum) are protected from interference by,
% e.g compute heavy applications. In addition, \name schedules applications on
% different processors to applications handling sensitive data from side-channel
% attacks by other applications.

%Advances:
%  MPUs
%    -- capabilities
%    -- MPU vs MMU (seed of both?)
%
%Trends:
%  M vs A
%    -- Why deeply embedded (M) still relevant
%    -- Maybe Pebble vs other watches example?
%
%  Multi-Core (really Multi-MCU?)
%    -- solid protection / boundary
%    -- compare with TrustZone?
%    -- App / HW specific; need to expose but can't feature / focus / rely on


\input{protection-pl}