security-doc/security-guide/section_hypervisor-selection.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE section [
<!ENTITY % openstack SYSTEM "openstack.ent">
%openstack;
]>
<section xmlns="http://docbook.org/ns/docbook"
  xmlns:xi="http://www.w3.org/2001/XInclude"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  version="5.0"
  xml:id="hypervisor-selection">
  <?dbhtml stop-chunking?>
  <title>Hypervisor selection</title>
  <para>Virtualization can provide flexibility, improved resource
    utilization, faster provisioning, and other benefits that enable
    cloud computing. The virtualization stack can also provide
    isolation between guest virtual machines, however, appropriate
    security measures must be considered to reduce the risks
    associated with hypervisor breakout attacks.</para>
  <para>This chapter discusses the hypervisor selection process. The
    chapters that follow provide foundational information needed for
    securing a virtualization stack.</para>
  <section xml:id="hypervisor-selection-hypervisors-in-openstack">
    <title>Hypervisors in OpenStack</title>
    <para>Whether OpenStack is deployed within private data centers or
      as a public cloud service, the underlying virtualization
      technology provides enterprise-level capabilities in the realms
      of scalability, resource efficiency, and uptime. While such
      high-level benefits are generally available across many
      OpenStack-supported hypervisor technologies, there are
      significant differences in the security architecture and
      features for each hypervisor, particularly when considering the
      security threat vectors which are unique to elastic OpenStack
      environments. As applications consolidate into single
      Infrastructure-as-a-Service (IaaS) platforms, instance isolation
      at the hypervisor level becomes paramount. The requirement for
      secure isolation holds true across commercial, government, and
      military communities.</para>
    <para>Within the OpenStack framework, you can choose among many
      hypervisor platforms and corresponding OpenStack plug-ins to
      optimize your cloud environment. In the context of this guide,
      hypervisor selection considerations are highlighted as they
      pertain to feature sets that are critical to security. However,
      these considerations are not meant to be an exhaustive
      investigation into the pros and cons of particular hypervisors.
      NIST provides additional guidance in Special Publication
      800-125, "<emphasis>Guide to Security for Full Virtualization
        Technologies</emphasis>".</para>
  </section>
  <section xml:id="hypervisor-selection-selection-criteria">
    <title>Selection criteria</title>
    <para>As part of your hypervisor selection process, you must
      consider a number of important factors to help increase your
      security posture. Specifically, you must become familiar with
      these areas:</para>
    <itemizedlist>
      <listitem>
        <para>Team expertise</para>
      </listitem>
      <listitem>
        <para>Product or project maturity</para>
      </listitem>
      <listitem>
        <para>Common criteria</para>
      </listitem>
      <listitem>
        <para>Certifications and attestations</para>
      </listitem>
      <listitem>
        <para>Hardware concerns</para>
      </listitem>
      <listitem>
        <para>Hypervisor vs. baremetal</para>
      </listitem>
      <listitem>
        <para>Additional security features</para>
      </listitem>
    </itemizedlist>
    <para>Additionally, the following security-related criteria are
      highly encouraged to be evaluated when selecting a hypervisor
      for OpenStack deployments:</para>
    <itemizedlist>
      <listitem>
        <para>Has the hypervisor undergone Common Criteria
          certification? If so, to what levels?</para>
      </listitem>
      <listitem>
        <para>Is the underlying cryptography certified by a
          third-party?</para>
      </listitem>
    </itemizedlist>
    <section xml:id="team_expertise">
      <title>Team expertise</title>
      <para>Most likely, the most important aspect in hypervisor
        selection is the expertise of your staff in managing and
        maintaining a particular hypervisor platform. The more
        familiar your team is with a given product, its configuration,
        and its eccentricities, the fewer the configuration mistakes.
        Additionally, having staff expertise spread across an
        organization on a given hypervisor increases availability of
        your systems, allows segregation of duties, and mitigates
        problems in the event that a team member is
        unavailable.</para>
    </section>
    <section xml:id="hypervisor-selection-selection-criteria-product-or-project-maturity">
      <title>Product or project maturity</title>
      <para>The maturity of a given hypervisor product or project is
        critical to your security posture as well. Product maturity
        has a number of effects once you have deployed your
        cloud:</para>
      <itemizedlist>
        <listitem>
          <para>Availability of expertise</para>
        </listitem>
        <listitem>
          <para>Active developer and user communities</para>
        </listitem>
        <listitem>
          <para>Timeliness and availability of updates</para>
        </listitem>
        <listitem>
          <para>Incidence response</para>
        </listitem>
      </itemizedlist>
      <para>One of the biggest indicators of a hypervisor's maturity
        is the size and vibrancy of the community that surrounds it.
        As this concerns security, the quality of the community
        affects the availability of expertise if you need additional
        cloud operators. It is also a sign of how widely deployed the
        hypervisor is, in turn leading to the battle readiness of any
        reference architectures and best practices.</para>
      <para>Further, the quality of community, as it surrounds an open
        source hypervisor like KVM or Xen, has a direct impact on the
        timeliness of bug fixes and security updates. When
        investigating both commercial and open source hypervisors, you
        must look into their release and support cycles as well as the
        time delta between the announcement of a bug or security issue
        and a patch or response. Lastly, the supported capabilities of
        OpenStack compute vary depending on the hypervisor chosen. See
        the <link
          xlink:href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix"
          >OpenStack Hypervisor Support Matrix</link> for OpenStack
        compute feature support by hypervisor.</para>
    </section>
    <section xml:id="hypervisor-selection-selection-criteria-certifications-and-attestations">
      <title>Certifications and attestations</title>
      <para>One additional consideration when selecting a hypervisor
        is the availability of various formal certifications and
        attestations. While they may not be requirements for your
        specific organization, these certifications and attestations
        speak to the maturity, production readiness, and thoroughness
        of the testing a particular hypervisor platform has been
        subjected to.</para>
    </section>
    <section xml:id="hypervisor-selection-selection-criteria-common-criteria">
      <title>Common criteria</title>
      <para>Common Criteria is an internationally standardized
        software evaluation process, used by governments and
        commercial companies to validate software technologies perform
        as advertised. In the government sector, NSTISSP No. 11
        mandates that U.S. Government agencies only procure software
        which has been Common Criteria certified, a policy which has
        been in place since July 2002. It should be specifically noted
        that OpenStack has not undergone Common Criteria
        certification, however many of the available hypervisors
        have.</para>
      <para>In addition to validating a technologies capabilities, the
        Common Criteria process evaluates <emphasis>how</emphasis>
        technologies are developed.</para>
      <itemizedlist>
        <listitem>
          <para>How is source code management performed?</para>
        </listitem>
        <listitem>
          <para>How are users granted access to build systems?</para>
        </listitem>
        <listitem>
          <para>Is the technology cryptographically signed before
            distribution?</para>
        </listitem>
      </itemizedlist>
      <para>The KVM hypervisor has been Common Criteria certified
        through the U.S. Government and commercial distributions,
        which have been validated to separate the runtime environment
        of virtual machines from each other, providing foundational
        technology to enforce instance isolation. In addition to
        virtual machine isolation, KVM has been Common Criteria
        certified to</para>
      <blockquote>
        <para>"<emphasis>provide system-inherent separation mechanisms
            to the resources of virtual machines. This separation
            ensures that large software component used for
            virtualizing and simulating devices executing for each
            virtual machine cannot interfere with each other. Using
            the SELinux multi-category mechanism, the virtualization
            and simulation software instances are isolated. The
            virtual machine management framework configures SELinux
            multi-category settings transparently to the
            administrator</emphasis>"</para>
      </blockquote>
      <para>While many hypervisor vendors, such as Red Hat, Microsoft,
        and VMware have achieved Common Criteria Certification their
        underlying certified feature set differs. It is recommended to
        evaluate vendor claims to ensure they minimally satisfy the
        following requirements:</para>
      <informaltable rules="all" width="80%">
        <colgroup>
          <col/>
          <col/>
        </colgroup>
        <tbody>
          <tr>
            <td><para>Identification and Authentication</para></td>
            <td><para>Identification and authentication using
                pluggable authentication modules (PAM) based upon user
                passwords. The quality of the passwords used can be
                enforced through configuration options.</para></td>
          </tr>
          <tr>
            <td><para>Audit</para></td>
            <td><para>The system provides the capability to audit a
                large number of events including individual system
                calls as well as events generated by trusted
                processes. Audit data is collected in regular files in
                ASCII format. The system provides a program for the
                purpose of searching the audit
                records.</para><para>The system administrator can
                define a rule base to restrict auditing to the events
                they are interested in. This includes the ability to
                restrict auditing to specific events, specific users,
                specific objects or a combination of all of
                this.</para><para>Audit records can be transferred to
                a remote audit daemon.</para></td>
          </tr>
          <tr>
            <td><para>Discretionary Access Control</para></td>
            <td>
              <para>Discretionary Access Control
                  (<glossterm>DAC</glossterm>) restricts access to
                file system objects based on <glossterm
                  baseform="access control list">Access Control
                  Lists</glossterm> (ACLs) that include the standard
                UNIX permissions for user, group and others. Access
                control mechanisms also protect IPC objects from
                unauthorized access.</para>
              <para>The system includes the ext4 file system, which
                supports POSIX ACLs. This allows defining access
                rights to files within this type of file system down
                to the granularity of a single user.</para>
            </td>
          </tr>
          <tr>
            <td><para>Mandatory Access Control</para></td>
            <td><para>Mandatory Access Control (MAC) restricts access
                to objects based on labels assigned to subjects and
                objects. Sensitivity labels are automatically attached
                to processes and objects. The access control policy
                enforced using these labels is derived from the
                <glossterm baseform="Bell-LaPadula model">Bell-LaPadula
                access control model</glossterm>.</para><para>SELinux
                categories are attached to virtual machines and its
                resources. The access control policy enforced using
                these categories grant virtual machines access to
                resources if the category of the virtual machine is
                identical to the category of the accessed
                resource.</para><para>The TOE implements
                non-hierarchical categories to control access to
                virtual machines.</para></td>
          </tr>
          <tr>
            <td><para>Role-Based Access Control</para></td>
            <td><para>Role-based access control (RBAC) allows
                separation of roles to eliminate the need for an
                all-powerful system administrator.</para></td>
          </tr>
          <tr>
            <td><para>Object Reuse</para></td>
            <td><para>File system objects and memory and IPC objects
                are cleared before they can be reused by a process
                belonging to a different user.</para></td>
          </tr>
          <tr>
            <td><para>Security Management</para></td>
            <td><para>The management of the security critical
                parameters of the system is performed by
                administrative users. A set of commands that require
                root privileges (or specific roles when RBAC is used)
                are used for system management. Security parameters
                are stored in specific files that are protected by the
                access control mechanisms of the system against
                unauthorized access by users that are not
                administrative users.</para></td>
          </tr>
          <tr>
            <td><para>Secure Communication</para></td>
            <td><para>The system supports the definition of trusted
                channels using SSH. Password based authentication is
                supported. Only a restricted number of cipher suites
                are supported for those protocols in the evaluated
                configuration.</para></td>
          </tr>
          <tr>
            <td><para>Storage Encryption</para></td>
            <td><para>The system supports encrypted block devices to
                provide storage confidentiality via
              dm_crypt.</para></td>
          </tr>
          <tr>
            <td><para>TSF Protection</para></td>
            <td><para>While in operation, the kernel software and data
                are protected by the hardware memory protection
                mechanisms. The memory and process management
                components of the kernel ensure a user process cannot
                access kernel storage or storage belonging to other
                processes.</para><para>Non-kernel TSF software and
                data are protected by DAC and process isolation
                mechanisms. In the evaluated configuration, the
                reserved user ID root owns the directories and files
                that define the TSF configuration. In general, files
                and directories containing internal TSF data, such as
                configuration files and batch job queues, are also
                protected from reading by DAC
                permissions.</para><para>The system and the hardware
                and firmware components are required to be physically
                protected from unauthorized access. The system kernel
                mediates all access to the hardware mechanisms
                themselves, other than program visible CPU instruction
                functions.</para><para>In addition, mechanisms for
                protection against stack overflow attacks are
                provided.</para></td>
          </tr>
        </tbody>
      </informaltable>
    </section>
    <section xml:id="hypervisor-selection-selection-criteria-cryptography-standards">
      <title>Cryptography standards</title>
      <para>Several cryptography algorithms are available within
        OpenStack for identification and authorization, data transfer
        and protection of data at rest. When selecting a hypervisor,
        the following are recommended algorithms and implementation
        standards to ensure the virtualization layer supports:</para>
      <informaltable rules="all" width="80%">
        <colgroup>
          <col/>
          <col/>
          <col/>
          <col/>
          <col/>
        </colgroup>
        <thead>
          <tr>
            <th>Algorithm</th>
            <th>Key length</th>
            <th>Intended purpose</th>
            <th>Security function</th>
            <th>Implementation standard</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>AES</td>
            <td>128, 192, or 256 bits</td>
            <td>Encryption / decryption</td>
            <td>Protected data transfer, protection for data at
                rest</td>
            <td><link
                  xlink:href="http://www.ietf.org/rfc/rfc4253.txt"
                  >RFC 4253</link></td>
          </tr>
          <tr>
            <td>TDES</td>
            <td>168 bits</td>
            <td>Encryption / decryption</td>
            <td>Protected data transfer</td>
            <td><link
                  xlink:href="http://www.ietf.org/rfc/rfc4253.txt"
                  >RFC 4253</link></td>
          </tr>
          <tr>
            <td>RSA</td>
            <td>1024, 2048, or 3072 bits</td>
            <td>Authentication, key exchange</td>
            <td>Identification and authentication, protected
                data transfer</td>
            <td><link
                  xlink:href="http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf"
                  >U.S. NIST FIPS PUB 186-3</link></td>
          </tr>
          <tr>
            <td>DSA</td>
            <td>L=1024, N=160 bits</td>
            <td>Authentication, key exchange</td>
            <td>Identification and authentication, protected
                data transfer</td>
            <td><link
                  xlink:href="http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf"
                  >U.S. NIST FIPS PUB 186-3</link></td>
          </tr>
          <tr>
            <td>Serpent</td>
            <td>128, 192, or 256 bits</td>
            <td>Encryption / decryption</td>
            <td>Protection of data at rest</td>
            <td><link
                  xlink:href="http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf"
                  >http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf</link></td>
          </tr>
          <tr>
            <td>Twofish</td>
            <td>128, 192, or 256 bit</td>
            <td>Encryption / decryption</td>
            <td>Protection of data at rest</td>
            <td><link
                  xlink:href="http://www.schneier.com/paper-twofish-paper.html"
                  >http://www.schneier.com/paper-twofish-paper.html</link></td>
          </tr>
          <tr>
            <td>SHA-1</td>
            <td>-</td>
            <td>Message Digest</td>
            <td>Protection of data at rest, protected data
                transfer</td>
            <td><link
                  xlink:href="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf"
                  >U.S. NIST FIPS PUB 180-3</link></td>
          </tr>
          <tr>
            <td>SHA-2 (224, 256, 384, or 512 bits)</td>
            <td>-</td>
            <td>Message Digest</td>
            <td>Protection for data at rest, identification and
                authentication</td>
            <td><link
                  xlink:href="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf"
                  >U.S. NIST FIPS PUB 180-3</link></td>
          </tr>
        </tbody>
      </informaltable>
      <section xml:id="hypervisor-selection-selection-criteria-cryptography-standards-fips-140-2">
        <title>FIPS 140-2</title>
        <para>In the United States the National Institute of Science
          and Technology (NIST) certifies cryptographic algorithms
          through a process known the Cryptographic Module Validation
          Program. NIST certifies algorithms for conformance against
          Federal Information Processing Standard 140-2 (FIPS 140-2),
          which ensures:</para>
        <blockquote>
          <para><emphasis>Products validated as conforming to FIPS
              140-2 are accepted by the Federal agencies of both
              countries [United States and Canada] for the protection
              of sensitive information (United States) or Designated
              Information (Canada). The goal of the CMVP is to promote
              the use of validated cryptographic modules and provide
              Federal agencies with a security metric to use in
              procuring equipment containing validated cryptographic
              modules.</emphasis></para>
        </blockquote>
        <para>When evaluating base hypervisor technologies, consider
          if the hypervisor has been certified against FIPS 140-2. Not
          only is conformance against FIPS 140-2 mandated per U.S.
          Government policy, formal certification indicates that a
          given implementation of a cryptographic algorithm has been
          reviewed for conformance against module specification,
          cryptographic module ports and interfaces; roles, services,
          and authentication; finite state model; physical security;
          operational environment; cryptographic key management;
          electromagnetic interference/electromagnetic compatibility
          (EMI/EMC); self-tests; design assurance; and mitigation of
          other attacks.</para>
      </section>
    </section>
    <section xml:id="hypervisor-selection-selection-criteria-hardware-concerns">
      <title>Hardware concerns</title>
      <para>Further, when you evaluate a hypervisor platform, consider
        the supportability of the hardware on which the hypervisor
        will run. Additionally, consider the additional features
        available in the hardware and how those features are supported
        by the hypervisor you chose as part of the OpenStack
        deployment. To that end, hypervisors each have their own
        hardware compatibility lists (HCLs). When selecting compatible
        hardware it is important to know in advance which
        hardware-based virtualization technologies are important from
        a security perspective.</para>
      <informaltable rules="all" width="80%">
        <colgroup>
          <col/>
          <col/>
          <col/>
        </colgroup>
        <thead>
          <tr>
            <td>Description</td>
            <td>Technology</td>
            <td>Explanation</td>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>I/O MMU</td>
            <td>VT-d / AMD-Vi</td>
            <td>Required for protecting
              PCI-passthrough</td>
          </tr>
          <tr>
            <td>Intel Trusted Execution Technology</td>
            <td>Intel TXT / SEM</td>
            <td>Required for dynamic attestation
              services</td>
          </tr>
          <tr>
            <td><anchor
                  xml:id="PCI-SIG_I.2FO_virtualization_.28IOV.29"
                />PCI-SIG I/O virtualization</td>
            <td>SR-IOV, MR-IOV, ATS</td>
            <td>Required to allow secure sharing of PCI Express
                devices</td>
          </tr>
          <tr>
            <td>Network virtualization</td>
            <td>VT-c</td>
            <td>Improves performance of network I/O on
                hypervisors</td>
          </tr>
        </tbody>
      </informaltable>
    </section>
    <section xml:id="hypervisor-selection-selection-criteria-hypervisor-vs-baremetal">
      <title>Hypervisor vs. baremetal</title>
      <para>It is important to recognize the difference between using
        LXC (Linux Containers) or baremetal systems vs using a
        hypervisor like KVM. Specifically, the focus of this security
        guide is largely based on having a hypervisor and
        virtualization platform. However, should your implementation
        require the use of a baremetal or LXC environment, you must
        pay attention to the particular differences in regard to
        deployment of that environment.</para>
      <para>In particular, you must assure your end users that the
        node has been properly sanitized of their data prior to
        re-provisioning. Additionally, prior to reusing a node, you
        must provide assurances that the hardware has not been
        tampered or otherwise compromised.</para>
      <note>
        <para>While OpenStack has a baremetal project, a discussion of
          the particular security implications of running baremetal is
          beyond the scope of this book.</para>
      </note>
      <para>Finally, due to the time constraints around a book sprint,
        the team chose to use KVM as the hypervisor in our example
        implementations and architectures.</para>
      <note>
        <para>There is an OpenStack Security Note pertaining to the
            <link
            xlink:href="https://bugs.launchpad.net/ossn/+bug/1098582"
            >use of LXC in Compute</link>.</para>
      </note>
    </section>
    <section xml:id="hypervisor-selection-selection-criteria-hypervisor-memory-optimization">
      <title>Hypervisor memory optimization</title>
      <para>Many hypervisors use memory optimization techniques to
        overcommit memory to guest virtual machines. This is a useful
        feature that allows you to deploy very dense compute clusters.
        One way to achieve this is through de-duplication or "sharing"
        of memory pages. When two virtual machines have identical data
        in memory, there are advantages to having them reference the
        same memory.</para>
      <para>Typically this is achieved through Copy-On-Write (COW)
        mechanisms. These mechanisms have been shown to be vulnerable
        to side-channel attacks where one VM can infer something about
        the state of another and might not be appropriate for
        multi-tenant environments where not all tenants are trusted or
        share the same levels of trust.</para>
    </section>
    <section xml:id="hypervisor-selection-selection-criteria-kvm-kernel-samepage-merging">
      <title>KVM Kernel Samepage Merging</title>
      <para>Introduced into the Linux kernel in version 2.6.32, Kernel
        Samepage Merging (KSM) consolidates identical memory pages
        between Linux processes. As each guest VM under the KVM
        hypervisor runs in its own process, KSM can be used to
        optimize memory use between VMs.</para>
    </section>
    <section xml:id="hypervisor-selection-selection-criteria-xen-transparent-page-sharing">
      <title>XEN transparent page sharing</title>
      <para>XenServer 5.6 includes a memory overcommitment feature
        named Transparent Page Sharing (TPS). TPS scans memory in 4 KB
        chunks for any duplicates. When found, the Xen Virtual Machine
        Monitor (VMM) discards one of the duplicates and records the
        reference of the second one.</para>
    </section>
    <section xml:id="hypervisor-selection-selection-criteria-security-considerations-for-memory-optimization">
      <title>Security considerations for memory optimization</title>
      <para>Traditionally, memory de-duplication systems are
        vulnerable to side channel attacks. Both KSM and TPS have
        demonstrated to be vulnerable to some form of attack. In
        academic studies attackers were able to identify software packages
        and versions running on neighboring virtual machines as well
        as software downloads and other sensitive information through
        analyzing memory access times on the attacker VM.</para>
      <para>If a cloud deployment requires strong separation of
        tenants, as is the situation with public clouds and some
        private clouds, deployers should consider disabling TPS and
        KSM memory optimizations.</para>
    </section>
    <section xml:id="hypervisor-selection-selection-criteria-additional-security-features">
      <title>Additional security features</title>
      <para>Another thing to look into when selecting a hypervisor
        platform is the availability of specific security features. In
        particular, we are referring to features like Xen Server's XSM
        or Xen Security Modules, sVirt, Intel TXT, and AppArmor. The
        presence of these features increase your security profile as
        well as provide a good foundation.</para>
      <para>The following table calls out these features by common
        hypervisor platforms.</para>
      <informaltable rules="all" width="80%">
        <colgroup>
          <col/>
          <col/>
          <col/>
          <col/>
          <col/>
          <col/>
          <col/>
        </colgroup>
        <tbody>
          <tr>
            <td><para/></td>
            <td><para>XSM</para></td>
            <td><para>sVirt</para></td>
            <td><para>TXT</para></td>
            <td><para>AppArmor</para></td>
            <td><para>cgroups</para></td>
            <td><para>MAC Policy</para></td>
          </tr>
          <tr>
            <td><para>KVM</para></td>
            <td><para/></td>
            <td><para>&CHECK;</para></td>
            <td><para>&CHECK;</para></td>
            <td><para>&CHECK;</para></td>
            <td><para>&CHECK;</para></td>
            <td><para>&CHECK;</para></td>
          </tr>
          <tr>
            <td><para>Xen</para></td>
            <td><para>&CHECK;</para></td>
            <td><para/></td>
            <td><para>&CHECK;</para></td>
            <td><para/></td>
            <td><para/></td>
            <td><para>&CHECK;</para></td>
          </tr>
          <tr>
            <td><para>ESXi</para></td>
            <td><para/></td>
            <td><para/></td>
            <td><para>&CHECK;</para></td>
            <td><para/></td>
            <td><para/></td>
            <td><para/></td>
          </tr>
          <tr>
            <td><para>Hyper-V</para></td>
            <td><para/></td>
            <td><para/></td>
            <td><para/></td>
            <td><para/></td>
            <td><para/></td>
            <td><para/></td>
          </tr>
        </tbody>
      </informaltable>
      <para>MAC Policy: Mandatory Access Control; may be implemented
        with SELinux or other operating systems</para>
      <para>* Features in this table might not be applicable to all
        hypervisors or directly mappable between hypervisors.</para>
    </section>
  </section>
  <section xml:id="hypversisor-selection-references">
    <title>Bibliography</title>
    <itemizedlist>
      <listitem>
        <para>
          Sunar, Eisenbarth, Inci, Gorka Irazoqui Apecechea. Fine Grain
          Cross-VM  Attacks on Xen and VMware are possible!. 2014. <link xlink:href="https://eprint.iacr.org/2014/248.pdf"
          >https://eprint.iacr.org/2014/248.pdf</link>
        </para>
      </listitem>
      <listitem>
        <para>
          Artho, Yagi, Iijima, Kuniyasu Suzaki. Memory Deduplication as
          a Threat to the Guest OS. 2011. <link xlink:href="https://staff.aist.go.jp/c.artho/papers/EuroSec2011-suzaki.pdf"
          >https://staff.aist.go.jp/c.artho/papers/EuroSec2011-suzaki.pdf</link>
        </para>
      </listitem>
      <listitem>
        <para>KVM: Kernal-based Virtual Machine. Kernal Samepage Merging. 2010. <link xlink:href="http://www.linux-kvm.org/page/KSM">KVM:
        Kernel Samepage Merging</link></para>
      </listitem>
      <listitem>
        <para>Xen Project, Xen Security Modules: XSM-FLASK. 2014. <link
          xlink:href="http://wiki.xen.org/wiki/Xen_Security_Modules_:_XSM-FLASK"
          >XSM: Xen Security Modules</link></para>
      </listitem>
      <listitem>
        <para>SELinux Project, SVirt. 2011. <link xlink:href="http://selinuxproject.org/page/SVirt"
          >xVirt: Mandatory Access Control for Linux-based
          virtualization</link></para>
      </listitem>
      <listitem>
        <para>Intel.com, Trusted Compute Pools with Intel Trusted
        Execution Technology (Intel TXT). <link xlink:href="http://www.intel.com/txt">TXT: Intel
          Trusted Execution Technology</link></para>
      </listitem>
      <listitem>
        <para>AppArmor.net, AppArmor Main Page. 2011. <link xlink:href="http://wiki.apparmor.net/index.php/Main_Page"
          >AppArmor: Linux security module implementing
        MAC</link></para>
      </listitem>
      <listitem>
        <para>Kernal.org, CGroups. 2004. <link xlink:href="https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt"
          >cgroups: Linux kernel feature to control resource
          usage</link></para>
      </listitem>
      <listitem>
        <para>Computer Security Resource Centre. Guide to Security for
        Full Virtualization Technologies. 2011. <link xlink:href="http://csrc.nist.gov/publications/nistpubs/800-125/SP800-125-final.pdf"
          >Guide to Security for Full Virtualization Technologies</link></para>
      </listitem>
      <listitem>
        <para>National Information Assurance Partnership, National Security
        Telecommunications and Information Systems Security Policy. 2003. <link xlink:href="http://www.niap-ccevs.org/cc-scheme/nstissp_11_revised_factsheet.pdf"
          >National Security Telecommunications and Information Systems Security Policy No. 11</link></para>
      </listitem>
    </itemizedlist>
  </section>
</section>