\begin{latexonly}
\svnInfo $Id$  
\end{latexonly}

Traditional commodity operating systems are monolithic programs that
directly manage all hardware, so any OS exploit results
in total system compromise.  A variety of architectures have been
proposed to mitigate the impact of an OS compromise by providing
memory and CPU isolation using a separate layer below the commodity
OS, either in the form of a virtual machine monitor, microkernel or
architectural extensions --- taking sole responsibility for
protection out of the hands of the OS.  

These architectures prevent a compromised OS from reading or modifying
application CPU and memory state. We are primarily interested not in
these attacks but rather what comes next, \emph{i.e.}~once we have
prevented direct attacks on application state, how we can prevent
higher-level attacks based on modifying the semantics of system
calls. However, CPU and memory isolation is a prerequisite for our
work, so we begin with a survey of these isolation architectures.

Microkernel-based architectures, such as those based on
L4~\cite{haertig05:_nizza_secur_system_archit}, divide both the
application and OS into multiple components, placing each in its own
process.  In Proxos, a virtual-machine-based system, trusted
components including the protected applications and a trusted ``private OS''
are placed in a single VM, that runs alongside another VM running a
commodity OS~\cite{ta-min06:_split_inter}. A proxy forwards the
application's system calls to either the private OS or commodity OS,
depending on an application-specific security policy. NGSCB takes a
similar, but less backwards-compatible approach, by requiring the
application to be refactored into a trusted part which runs in its own
secure compartment and an untrusted part which runs on the commodity
OS~\cite{england03:_trust_open_platf}.  XOM is a processor
architecture that isolates protected applications from each other and
the operating system using a combination of register-level tagging and
cryptographic techniques~\cite{lie00:_archit_suppor_for_copy_and}.


%This isolation barrier is often imposed 
%taking advantage of the standard isolation barrier provided by the
%microkernel or virtual machine monitor. In the microkernel-based
%systems, each component of the application and of the OS executes in
%its own process. 

While seemingly different, all these architectures provide the same
basic property: some or all of the application is run in a separate
protection domain from the OS. This protects the secrecy and integrity
of resources like registers and memory, and ensures control flow
integrity, \emph{i.e.}~control flow cannot be altered except via
well-defined protocols such as signal delivery and system calls.

\paragraph{Overshadow.}

Overshadow~\cite{chen08:_overs} is a system we developed for
protecting applications running inside a VM from the operating
system in that VM.  Overshadow works by leveraging the virtual
machine monitor's control over memory mappings to present different
views of memory pages depending on the execution context.  When an
application accesses its own memory, access proceeds as normal; if
the OS or another application accesses it, the VMM transparently
encrypts the memory page and saves a secure hash for integrity
verification.  This allows all resource management functionality to
remain in the hands of the OS, without compromising secrecy and
integrity: for example, the OS can swap memory pages to disk and
restore them, but cannot read or modify their contents.

%Accordingly, it is possible to use a greatly simplified VMM,
%reducing TCB complexity.  \begin{ednote}{DRKP} Make sure ``TCB'' is
%defined someplace.  \end{ednote}

To adapt applications to this new execution environment, without
requiring any modifications to the application or OS, we add a
\emph{shim} to each application at load time.  The shim is user-level
code (akin to a shared library), but communicates directly with the
VMM via a \emph{hypercall} interface.  The shim and VMM together
provide secure control transfer by saving execution state in protected
memory when an application is interrupted, and restoring it when the
application resumes execution. The VMM also redirects system calls
to the shim, which adapts their semantics as necessary
for compatibility; for example, data being passed to the OS is
automatically copied to unprotected memory so that the OS can access
it. In the extensions to Overshadow we propose in
Section~\ref{sec:components}, we make use of this system call
interposition to help implement system calls securely.

\begin{figure}[t]
  \centering
  \imgsrc{architecture.png}
  \begin{latexonly}
    \includegraphics[scale=0.5]{architecture}    
  \end{latexonly}
  \caption{Overshadow architecture. Trusted components are indicated
    with a shaded background. In addition to the standard
    virtualization barrier that isolates entire VMs from each other
    and the monitor, Overshadow adds a second virtualization barrier
    that isolates protected applications from other components inside
    the same VM.}
  \label{fig:architecture}
\end{figure}

Figure~\ref{fig:architecture} shows the components required to protect
an application with Overshadow. In addition to the
application itself, the shim, VMM, and hardware are trusted. The OS
kernel and all other applications, including privileged daemons and
other system services, are untrusted.


Overshadow uses a simple protection model based on whole-application
protection. Each application runs in its own secure compartment
identified by a unique \emph{security ID} (SID). Each process or
thread thus has an associated SID. Every resource, such as a memory
region or file, has an owner SID. Access to a resource is permitted
only if its SID is the same as that of the currently-executing
thread. Though simple, this model is sufficient for many interesting
applications. It would be relatively straightforward to extend this
model to support trust relationships between applications and more
sophisticated access control for shared resources.

%\paragraph{L4.}

%Several systems have been build based on the L4 Micokernel. blah.
%blah.


%%% Local Variables: 
%%% mode: latex
%%% TeX-command-default: "Make"
%%% TeX-PDF-mode: t
%%% TeX-master: "paper"
%%% End: 

% Prior work has focused on providing memory and CPU isolation
% to mitigate the impact of an OS compromise i.e.~providing
% seperate protection domains for security isolation. While
% we don't want to dwell to long on how basic protection
% are provided, we will begin by providing some background on
% architectures our discuss is relavent to, most specifically about
% our system, Overshadow, that provides a new orthogonal protection
% domain for running applications inside of a virtual machine --
% allowing an applications memory, cpu resources, etc.to be protected
% from a malicous operating. With this background in-place, we can
% then dive into our discussion of less direct OS attacks e.g.~
% those based on modifying the semantics of system calls, as opposed
% to more low level attacks which directly modify application CPU or
% memory, which are prevented by these protection architectures.

%A necessary first step towards securing applications against
%compromised operating systems is establishing a secure execution
%environment. Otherwise, the OS could trivially obtain or tamper with
%an application's sensitive data simply by accessing its
%memory. Fortunately, several systems already exist to address this
%problem. In this section, we review the properties provided by these
%systems and how they achieve them.


%Different placing code in diprotection domains, in either traditional (e.g.

%

%Application secrecy Resource secrecy application code, data, and register
  %state cannot be read from outside its compartment
  
%an application's memory is
  %modified by the OS or another application, the tampering will be
  %detected and the application terminated.
  
%\item \textbf{Secure control transfer:} if an application's execution
  %is interrupted by a fault or interrupt, it may only be resumed in
  %the same execution context. Control transfers into and out of a
  %protected application can only take place via well-defined
  %interfaces such as system calls and signals.
%\end{itemize}


% LocalWords:  Microkernel microkernel