Figure 1: (a) In-VM and (b) Out-of-VM monitoring
hypervisor protected guest address space that can only be entered
and exited through specially constructed protected gates. In other
words, our system is designed in such a way that normal operation
of the monitor can continue without hypervisor intervention, but
any attempts to breach the security of SIM is trapped and prevented
by the hypervisor. Our system design leverages Intel VT [9] hard-
ware virtualization extensions and the virtual memory protections
available in standard Intel processors.
We have developed a prototype of the SIM framework based on
KVM [14], an open-source virtual machine monitor available as
part of mainstream Linux that exclusively uses hardware virtual-
ization features. Microbenchmarks show that an invocation of the
monitor in SIM is almost 11 times faster than that of a monitor re-
siding in a separate VM. As a demonstration of our framework, we
have developed a process creation monitor that allows a selected
list of processes to be executed. According to our microbench-
marks, out-of-VM monitoring introduced an overhead of 690%,
which includes external introspection costs, whereas the overhead
introduced by SIM was only 13%. We have also developed a stan-
dard system call interception monitor for the Windows OS. Macro
benchmarks carried over a number of representative benchmark
programs show an average overhead of 4.15% compared to 46.10%
of out-of-VM system call monitoring.
We summarize the contributions of our work below:
∙ Leveraging hardware virtualization and memory protection
features, we propose the Secure In-VM Monitoring frame-
work where a security monitor code can reside inside a guest
VM but still enjoy the same security benefits of out-of-VM
monitors (see Section 2 and Section 3).
∙ We have implemented a prototype of the SIM framework
based on KVM and Windows guest OS (see Section 4). For
demonstration, we have developed two security monitoring
applications using our framework. We provide experimental
evaluation of the performance overhead. (see Section 5).
∙ We provide a systematic security analysis of SIM against a
number of possible threats throughout the paper, and show
that SIM provides no less security guarantees than what can
be achieved by out-of-VM monitors.
The SIM framework should provide performance benefits to a
large number of security monitoring tools that utilize virtual ma-
chines, and at the same time enable new applications that were not
possible before due to the large overhead of out-of-VM monitoring.
2 Background and Requirements
A large fraction of security problems today are caused by kernel-
level attacks or malicious code such as rootkits that violate some
form of security in the entire system. Security tools such as anti-
viruses, intrusion detection systems, and security reference moni-
tors (e.g., SELinux) use various forms of event handling in a system
in order to verify the system’s security. We use the term monitor to
represent the class of all security tools that either actively intercept
events or passively analyze a system for violations of security.
If a monitor resides inside the same operating system it protects,
the monitor itself can be compromised by kernel-level attacks. This
problem is addressed by using virtualization. In virtual machine
monitors, the hypervisor intervenes executions of the guest VM
to give a virtual view of the real hardware. This is performed by
utilizing the higher privilege of the hypervisor over the kernel to
intercept accesses to the underlying hardware. Previous software-
based virtualization utilizes a reduced privilege guest kernel, so that
a higher privileged hypervisor can exist without any hardware sup-
port for virtualization. Recent processors include hardware virtual-
ization [9] features to enable thin and light-weight virtual machine
monitors. The privileged hypervisor allows various security ap-
proaches to protect access to hardware in an untrusted guest VM,
and have security tools isolated from the untrusted system by plac-
ing them in a separate VM.
We illustrate two approaches of security monitoring in Figure 1.
Figure 1(a) shows the model when the monitor resides in the same
untrusted environment. We call this In-VM approach. The isolated
monitor approach in a separate VM is shown in Figure 1(b), which
we call Out-of-VM approach. At the high-level, In-VM approach
provides performance and the Out-of-VM approach provides secu-
rity. We define the performance requirements based on the In-VM
approach and the security requirements from the Out-of-VM ap-
proach. The goal of our work is to design a system that satisfies
both the performance and security requirements.
We present a few formal notations for precision and clarity in
the following discussion. Assume that a system 𝑃 is being moni-
tored by a security monitor 𝑀 . The system contains code 𝐶
𝑃
and
data 𝐷
𝑃
and the monitor has its code 𝐶
𝑀
along with its private
data 𝐷
𝑀
. For passive monitoring the monitoring code 𝐶
𝑀
usually
needs to analyze the system code and data and use its own data to
verify the security of the system. For active monitoring, since an
event needs to be intercepted, a set of hooks 𝐾 = {𝑘
1
, 𝑘
2
, ..., 𝑘
𝑛
}
are placed in the monitored system that invokes corresponding han-
dlers in the set 𝐻 = {ℎ
1
, ℎ
2
, ..., ℎ
𝑛
} contained the monitoring
code 𝐶
𝑀
. A hook can pass data 𝐷
𝐾
related to the event that is
gathered at the point of the hook. After the handler handles the
hooked event, a response 𝑅 can transfer control to any specific
point in the system. It is obvious that the active monitoring model
subsumes the passive monitoring case.
The overhead in executing security tools out of the guest OS is
primarily due to the change in privilege levels that occurs while
switching back and forth between the kernel-level and the hypervisor-
level. We set the performance requirements for SIM’s design to be
the same as provided by In-VM approaches.
∙ (P1) Fast invocation: Invoking the monitors handler 𝐻 for
a hook 𝐾 should not involve any privilege level changes.
∙ (P2) Data read/write at native speed: The monitor code
𝐶
𝑀
should be able to read and write any system data 𝐷
𝑃
and