% Section for Implementation

% Section for Implementation

%

\section{Implementation}

We started with the Linux Android SDK that is comprised of APIs and developer tools necessary to begin developing applications on the Android platform. The SDK comes with an emulator which is a customized version of QEMU that runs a virtual ARM system-on-a-chip (SoC) that Google calls Goldfish. The Goldfish platform boots an ARM Linux kernel with Goldfish support compiled for the ARMv5TEJ instruction set.

We initially attempted to build and run a VMM targeting the Android platform that was implemented as part of a previous research project at the University of Illinois \cite{kallaembedded}. After downloading the source and working with project owners, we were unable to run a fully functional VMM on our configuration. In addition, we investigated porting the OKL4 Microvisor from Open Kernel Labs \cite{OKL4} to the Android platform, but found the porting process to be too complicated for our scope of work. At this point, we decided to implement our VMM interface by adding a simple hardware device to the Goldfish emulator. Figure ~\ref{fig:vmm_implementation} demonstrates the interactions between our emulated VMM and the host operating system.

%%%%%%%%

% vmm implementation

%%%%%%%%

\begin{figure}

\includegraphics[width=3.2in]{vmm_implementation.JPG}

\caption{VMM Design}

\label{fig:vmm_implementation}

\end{figure}

\item The emulated VMM is driven by a virtualized timer that is capable of being programmed to expire at predefined intervals. When a timer interval expires, the underlying emulator generates an interrupt which is then handled by the VMM.

We initially planned to have the trusted kernel module exist as an LKM that could be dynamically loaded or unloaded by the user. However, since our approach is attempting to prevent attacks by kernel-mode rootkits and user-mode malware with root access, it makes more sense to have a static trusted kernel module that is loaded as a permanent component of the kernel itself. This decision simplified the interface between the VMM and the kernel module greatly. The interface only needs to include the hardware interrupt that invokes the kernel module’s OS integrity check as an ISR, whereas the LKM approach would require a secure mechanism to report the trusted LKM’s load address. Dynamic loading would also call timing of the kernel module load into question from a security standpoint, as it would be difficult to ascertain whether the OS had already been compromised prior to the protection functionality being initialized and activated. The risks in ensuring such a mechanism could operate securely under all scenarios made the static kernel module a superior choice for our purposes.