%perspective, this is problematic: even if the application itself is
%implemented correctly, its security depends on the operating system
%being free of exploitable bugs. The operating system components that
%must be trusted make up an enormous body of code --- not just the
%kernel but also device drivers, privileged system services, and
%libraries --- and vulnerabilities are hardly uncommon. 

%Several architectures for high-assurance operating systems, such as
%those based on microkernels, have been proposed to address this
%problem
%(\emph{e.g.}~\cite{eros,haertig05:_nizza_secur_system_archit}). However,
%these typically require substantial modifications to applications,
%presenting a barrier to adoption. We seek a solution that retains
%compatibility with legacy applications.

%Recently, several architectural solutions have been proposed for
%retrofitting protection onto existing applications and operating
%systems, including
%XOM~\cite{lie00:_archit_suppor_for_copy_and,lie03:_implem_untrus_operat_system_trust_hardw},
%Proxos~\cite{ta-min06:_split_inter}, and
%Overshadow~\cite{chen08:_overs}. These systems use a thin trusted
%layer beneath the OS to enforce isolation between the OS and
%applications running on it. Specifically, they prevent the operating
%system from accessing application memory, files, or register state,
%and detect any attempts by the OS to tamper with these
%resources.

%This raises an interesting question: \emph{is it possible to
%guarantee privacy of application data, even if the underlying
%operating system is compromised?} At first glance, the systems
%described above seem to have solved this problem by allowing an
%untrusted operating system to manage resources without having access
%to their contents. We will show, however, that they are only a first
%step towards a complete solution. Although they remove an
%application's implicit dependency on the OS for managing its
%execution environment, there remain explicit dependencies where the
%application relies on services provided by the OS, \emph{e.g.\ }
%through system calls. These services might include file system
%management, IPC, I/O, or process management, among others.

%In this paper, we explore the nature of these dependencies. 

%perspective, this is problematic: even if the application itself is
%implemented correctly, its security depends on the operating system
%being free of exploitable bugs. The operating system components that
%must be trusted make up an enormous body of code --- not just the
%kernel but also device drivers, privileged system services, and
%libraries --- and vulnerabilities are hardly uncommon. 

%Several architectures for high-assurance operating systems, such as
%those based on microkernels, have been proposed to address this
%problem
%(\emph{e.g.}~\cite{eros,haertig05:_nizza_secur_system_archit}). However,
%these typically require substantial modifications to applications,
%presenting a barrier to adoption. We seek a solution that retains
%compatibility with legacy applications.

%Recently, several architectural solutions have been proposed for
%retrofitting protection onto existing applications and operating
%systems, including
%XOM~\cite{lie00:_archit_suppor_for_copy_and,lie03:_implem_untrus_operat_system_trust_hardw},
%Proxos~\cite{ta-min06:_split_inter}, and
%Overshadow~\cite{chen08:_overs}. These systems use a thin trusted
%layer beneath the OS to enforce isolation between the OS and
%applications running on it. Specifically, they prevent the operating
%system from accessing application memory, files, or register state,
%and detect any attempts by the OS to tamper with these
%resources.

%This raises an interesting question: \emph{is it possible to
%guarantee privacy of application data, even if the underlying
%operating system is compromised?} At first glance, the systems
%described above seem to have solved this problem by allowing an
%untrusted operating system to manage resources without having access
%to their contents. We will show, however, that they are only a first
%step towards a complete solution. Although they remove an
%application's implicit dependency on the OS for managing its
%execution environment, there remain explicit dependencies where the
%application relies on services provided by the OS, \emph{e.g.\ }
%through system calls. These services might include file system
%management, IPC, I/O, or process management, among others.

%In this paper, we explore the nature of these dependencies. 

%perspective, this is problematic: even if the application itself is
%implemented correctly, its security depends on the operating system
%being free of exploitable bugs. The operating system components that
%must be trusted make up an enormous body of code --- not just the
%kernel but also device drivers, privileged system services, and
%libraries --- and vulnerabilities are hardly uncommon. 

%Several architectures for high-assurance operating systems, such as
%those based on microkernels, have been proposed to address this
%problem
%(\emph{e.g.}~\cite{eros,haertig05:_nizza_secur_system_archit}). However,
%these typically require substantial modifications to applications,
%presenting a barrier to adoption. We seek a solution that retains
%compatibility with legacy applications.

%Recently, several architectural solutions have been proposed for
%retrofitting protection onto existing applications and operating
%systems, including
%XOM~\cite{lie00:_archit_suppor_for_copy_and,lie03:_implem_untrus_operat_system_trust_hardw},
%Proxos~\cite{ta-min06:_split_inter}, and
%Overshadow~\cite{chen08:_overs}. These systems use a thin trusted
%layer beneath the OS to enforce isolation between the OS and
%applications running on it. Specifically, they prevent the operating
%system from accessing application memory, files, or register state,
%and detect any attempts by the OS to tamper with these
%resources.

%This raises an interesting question: \emph{is it possible to
%guarantee privacy of application data, even if the underlying
%operating system is compromised?} At first glance, the systems
%described above seem to have solved this problem by allowing an
%untrusted operating system to manage resources without having access
%to their contents. We will show, however, that they are only a first
%step towards a complete solution. Although they remove an
%application's implicit dependency on the OS for managing its
%execution environment, there remain explicit dependencies where the
%application relies on services provided by the OS, \emph{e.g.\ }
%through system calls. These services might include file system
%management, IPC, I/O, or process management, among others.

%In this paper, we explore the nature of these dependencies. 


%XOM supports an
%operating system that takes advantage of its cryptographic protection
%of memory to load program code and swap memory pages to disk without
%being able to access their
%contents~\cite{lie03:_implem_untrus_operat_system_trust_hardw}.
%XOM also provides operations for saving register state in
%encrypted form, which allows for control flow integrity.