\svnInfo $Id$


Traditional commodity operating systems are monolithic programs that
directly manage all hardware resources, making the idea of security in
the event of a compromise hopeless. However, a variety of new
architectures have recently been proposed that can potentially
mitigate the impact of an OS compromise by providing memory and CPU
isolation using a separate layer below the commodity OS, either by way
of a VMM, microkernel or architecture extensions --- taking sole
responsibility for protection out of the hands of the
OS. These prevent attacks in which the OS directly reads or modifies
application CPU or memory state. We focus not on the attacks these
architectures prevent, but rather on 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.  Nevertheless, our work builds on
the presence of an isolation architecture, so we begin by
surveying these approaches.

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, all trusted components (the
protected applications and a trusted ``private OS'') are placed in a
single VM, which runs alongside another VM running a commodity OS. A
proxy forwards the application's system calls to either the private OS
or commodity OS, depending on an application-specific security
policy. NGSCB~\cite{england03:_trust_open_platf} 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.

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
fundamental property: different protection domains are isolated from
each other --- and some or all of the application is run in a
separate protection domain from the OS. Isolation protects the secrecy
and integrity of resources like registers and memory, in addition to
providing 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.}

We present our discussion in the context of our own work on
Overshadow, a virtual-machine-based system that uses the memory
indirection provided by virtualization to protect entities inside a
VM~\cite{chen08:_overs}. Its core primitive is
\emph{multi-shadowing}, which provides multiple views of memory:
when an application accesses its own memory, it sees its data as
normal, but if the OS or another application accesses it, the VMM
transparently encrypts the memory page. This guarantees secrecy
while still allowing the OS to manage resources. Overshadow also
guarantees memory integrity by storing a secure hash of each
encrypted memory page in a table indexed by virtual memory access.
Because all resource management is delegated to the untrusted
operating system, it is possible to use a greatly simplified VMM to
reduce the size of the TCB; for example, the VMM runs only a single
VM, so it does not need a CPU scheduler.

To adapt applications to this new execution environment, we add a
user-level \emph{shim} to each application at load time.  This
allows Overshadow to support completely unmodified applications and
operating systems.  The shim cooperates with the VMM to provide
secure control transfer by storing execution state in protected
memory. The shim also interposes on application system calls,
adapting 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 securely implement
system calls.

%\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