Open Source


Top Projects


System Integration



VisorFlow: A simple information-flow-based security monitor which runs in a hypervisor

Guest VM

After saving the following files to your computer and decompressing them, you can boot the guest using xl create visorflow-guest-linux.cfg. The root password is password.

Disk image
Spare disk image
Domain configuration (you must modify the paths contained therein to suit your environment)


We intend that VisorFlow implement a very simple information-flow-based security monitor which uses virtual-machine introspection to mediate system calls taking place in guest virtual machines. VisorFlow replaces SimpleFlow's kernel-based mechanism with a hypervisor-introspection-based mechanism.

VisorFlow architecture

While the above diagram is incomplete, it does give some indication of how VisorFlow will work. We plan to build VisorFlow from six components:

  1. the Xen hypervisor;
  2. Linux, running in a Dom0 domain;
  3. one or more copies of Linux or Windows, running in DomU domains;
  4. one or more processes, running upon each DomU operating system;
  5. the VisorFlow security monitor;
  6. the VisorFlow's Linux engine;
  7. the VisorFlow's Windows engine;
  8. the VisorFlow's network engine;
  9. firewalld; and
  10. the network filter (not pictured).

Consider process pn in DomU which invokes a system call (a). The act of invoking a system call normally involves the operating system (b), but here it also involves the hypervisor (c) and—through libvmi—the VisorFlow security monitor (d). The VisorFlow security monitor observes such system calls and their effect on information as it flows between processes, and the security monitor's operating-system engines use these observations to implement a taint-tracking system which resembles SimpleFlow.

In the case of network-I/O system calls, the VisorFlow network engine works with Dom0 and the hypervisor to mark as evil packets originating from tainted processes and to taint processes which receive marked packets. For example, if the Linux engine infers that a system call from a tainted process pn would result in network traffic, the Linux engine would notify the network engine (e). The network engine in turn adds a network filter rule to the host firewall through firewalld which has the affect of labeling pn's packets as evil (f). The added rule involves instructing NetFilter to rely on VisorFlow to actually set the evil bit using the NFQUEUE interface (g). Later, the Linux engine might infer that pn exited; when this happens, the Linux engine and network engine will remove the firewall rule which labeled pn's packets as evil.

Each operating-system-specific engine implements a different model upon which it relies to make decisions about the system. The models encompass:

(This is very provisional.) We expect that VisorFlow will make use of the following to communicate between components:

Input to security monitor
The security monitor will make use of the libvmi API in a way which resembles Ryan Johnson's guestrace. It will also accept keyboard input to its console and NFQUEUE input.
Security monitor to operating-system-specific engine
Internal API to be designed.
operating-system-specific engine to network engine
Internal API to be designed.
Network engine to firewalld
Firewalld's D-BUS interface.

This primary advantage of VisorFlow over SimpleFlow is that VisorFlow needs no kernel modifications to operate. This has two important consequences: (1) VisorFlow can mediate closed-source operating systems such as Windows, and (2) VisorFlow avoids difficult-to-maintain modifications to open-source kernels. We expect that these advantages will come at some cost of performance, but we do not yet know to what degree.

By combining aspects of access-control and provenance systems, VisorFlow removes the race conditions found in some provenance systems.

Email: — ✉ 315A South Moore Loop; West Point, New York 10996; USA