Abstract-An essential goal of Virtual Machine Introspection (VMI) is assuring security policy enforcement and overall functionality in the presence of an untrustworthy OS. A fundamental obstacle to this goal is the difficulty in accurately extracting semantic meaning from the hypervisor's hardwarelevel view of a guest OS, called the semantic gap. Over the twelve years since the semantic gap was identified, immense progress has been made in developing powerful VMI tools.Unfortunately, much of this progress has been made at the cost of reintroducing trust into the guest OS, often in direct contradiction to the underlying threat model motivating the introspection. Although this choice is reasonable in some contexts and has facilitated progress, the ultimate goal of reducing the trusted computing base of software systems is best served by a fresh look at the VMI design space.This paper organizes previous work based on the essential design considerations when building a VMI system, and then explains how these design choices dictate the trust model and security properties of the overall system. The paper then observes portions of the VMI design space which have been under-explored, as well as potential adaptations of existing techniques to bridge the semantic gap without trusting the guest OS.Overall, this paper aims to create an essential checkpoint in the broader quest for meaningful trust in virtualized environments through VM introspection.

No abstract

No abstract

An essential goal of virtual machine introspection (VMI) is security policy enforcement in the presence of an untrustworthy OS. One obstacle to this goal is the diffi culty in accurately extracting semantic meaning from the hypervisor's hardware-level view of a guest OS.V irtual machine introspection (VMI) techniques allow an external security monitor to observe soft ware behavior inside a virtual machine (VM), including the guest OS. For example, we can use VMI to list programs running inside a VM-comparable to ps on Unix systems or Windows Task Manager. Obtaining a process list outside a VM is appealing from a security perspective because security administrators can identify illicit programs on a system, even if the OS kernel is compromised. Th ere are also nonsecurity benefi ts to listing processes outside the VM, such as standardization of administrative utilities across multiple guest OSs.A simple VMI-based process list would identify process descriptors' memory addresses and typecast them (in C parlance) to interpret their content. VMI developers must fi nd the kernel data structures, such as process descriptors, by searching publicly available symbols for the addresses of the process descriptors' data structure.Any guest OS abstraction can be introspected, including open fi le descriptors, network sockets, and interprocess communication abstractions. For instance, storage system prototypes have used VMI to track whether disk writes are data or metadata, writing metadata changes to disk more aggressively than data. 1 In this article, we focus on in-memory data structures and CPU register state.VMI is appealing because it can move OS security monitoring out of the OS. Widely used OS kernels are generally very large and aff ord litt le fault or security isolation among components; are writt en in languages such as C or C++ that off er litt le protection against exploitable programmer errors; and have complex, hard-to-secure APIs. Th us, if any OS kernel component has an exploitable bug, all OS-level security measures are easily disabled.In our process listing example, a rootkit module could tamper with the kernel's mechanism for listing the set of running processes, oft en to hide other malware running on the system. Not only could an eff ective rootkit hide malware from a process listing utility or antivirus system inside the OS, it could also avoid detection and removal. A VMI monitor can view all guest OS memory and identify rootkits.Th e fundamental challenge underlying VMI is how to reliably infer what's happening in the guest OS. In our simple example, the VMI monitor has direct access only to hardware-level states, such as CPU registers and memory contents, and must make inferences about high-level abstractions, such as process descriptors and

Graph robustness is a measure of resilience to failures and targeted attacks. A large body of research on robustness focuses on how to attack a given network by deleting a few nodes so as to maximally disrupt its connectedness. As a result, literature contains a myriad of attack strategies that rank nodes by their relative importance for this task. How different are these strategies? Do they pick similar sets of target nodes, or do they differ significantly in their choices?In this paper, we perform the first large scale empirical correlation analysis of attack strategies, i.e., the node importance measures that they employ, for graph robustness. We approach this task in three ways; by analyzing similarities based on (i) their overall ranking of the nodes, (ii) the characteristics of top nodes that they pick, and (iii) the dynamics of disruption that they cause on the network. Our study of 15 different (randomized, local, distance-based, and spectral) strategies on 68 real-world networks reveals surprisingly high correlations among node-attack strategies, consistent across all three types of analysis, and identifies groups of comparable strategies. These findings suggest that some computationally complex strategies can be closely approximated by simpler ones, and a few strategies can be used as a close proxy of the consensus among all of them.