xen-vtpm



  • INTRODUCTION
        The goal of this work is to provide a TPM functionality to a virtual guest
        operating system (a DomU). This allows programs to interact with a TPM in
        a virtual system the same way they interact with a TPM on the physical
        system. Each guest gets its own unique, emulated, software TPM. However,
        each of the vTPM's secrets (Keys, NVRAM, etc) are managed by a vTPM
        Manager domain, which seals the secrets to the Physical TPM. If the
        process of creating each of these domains (manager, vTPM, and guest) is
        trusted, the vTPM subsystem extends the chain of trust rooted in the
        hardware TPM to virtual machines in Xen. Each major component of vTPM is
        implemented as a separate domain, providing secure separation guaranteed
        by the hypervisor. The vTPM domains are implemented in mini-os to reduce
        memory and processor overhead.
    
        This mini-os vTPM subsystem was built on top of the previous vTPM work
        done by IBM and Intel corporation.
    
    DESIGN OVERVIEW
        The architecture of vTPM is described below:
    
            +------------------+
            |    Linux DomU    | ...
            |       |  ^       |
            |       v  |       |
            |   xen-tpmfront   |
            +------------------+
                    |  ^
                    v  |
            +------------------+
            | mini-os/tpmback  |
            |       |  ^       |
            |       v  |       |
            |  vtpm-stubdom    | ...
            |       |  ^       |
            |       v  |       |
            | mini-os/tpmfront |
            +------------------+
                    |  ^
                    v  |
            +------------------+
            | mini-os/tpmback  |
            |       |  ^       |
            |       v  |       |
            | vtpmmgr-stubdom  |
            |       |  ^       |
            |       v  |       |
            | mini-os/tpm_tis  |
            +------------------+
                    |  ^
                    v  |
            +------------------+
            |   Hardware TPM   |
            +------------------+
    
        Linux DomU
            The Linux based guest that wants to use a vTPM. There many be more
            than one of these.
    
        xen-tpmfront.ko
            Linux kernel virtual TPM frontend driver. This driver provides vTPM
            access to a para-virtualized Linux based DomU.
    
        mini-os/tpmback
            Mini-os TPM backend driver. The Linux frontend driver connects to this
            backend driver to facilitate communications between the Linux DomU and
            its vTPM. This driver is also used by vtpmmgr-stubdom to communicate
            with vtpm-stubdom.
    
        vtpm-stubdom
            A mini-os stub domain that implements a vTPM. There is a one to one
            mapping between running vtpm-stubdom instances and logical vtpms on
            the system. The vTPM Platform Configuration Registers (PCRs) are all
            initialized to zero.
    
        mini-os/tpmfront
            Mini-os TPM frontend driver. The vTPM mini-os domain vtpm-stubdom uses
            this driver to communicate with vtpmmgr-stubdom. This driver could
            also be used separately to implement a mini-os domain that wishes to
            use a vTPM of its own.
    
        vtpmmgr-stubdom
            A mini-os domain that implements the vTPM manager. There is only one
            vTPM manager and it should be running during the entire lifetime of
            the machine. This domain regulates access to the physical TPM on the
            system and secures the persistent state of each vTPM.
    
        mini-os/tpm_tis
            Mini-os TPM version 1.2 TPM Interface Specification (TIS) driver. This
            driver used by vtpmmgr-stubdom to talk directly to the hardware TPM.
            Communication is facilitated by mapping hardware memory pages into
            vtpmmgr-stubdom.
    
        Hardware TPM
            The physical TPM that is soldered onto the motherboard.
    
    INSTALLATION
      Prerequisites:
        You must have an x86 machine with a TPM on the motherboard. The only extra
        software requirement for compiling vTPM is cmake. You must use libxl to
        manage domains with vTPMs; 'xm' is deprecated and does not support vTPMs.
    
      Compiling the Xen tree:
        Compile and install the Xen tree as usual; be sure that the vTPM domains
        are enabled when you run configure.
    
      Compiling the LINUX dom0 kernel:
        Because the TPM manager uses direct access to the physical TPM, it may
        interfere with access to the TPM by dom0. The simplest solution for this
        is to prevent dom0 from accessing the physical TPM by compiling the kernel
        without a driver or blacklisting the module. If dom0 needs a TPM but does
        not need to use it during the boot process (i.e. it is not using IMA), a
        virtual TPM can be attached to dom0 after the system is booted.
    
        Access to the physical TPM may be required in order to manage the NVRAM or
        to perform other advanced operations where the vTPM is insufficient. In
        order to prevent interference, the TPM Manager and dom0 should use
        different values for the TPM's locality; since Linux always uses locality
        0, using locality 2 for the TPM Manager is recommended. If both Linux and
        the TPM Manager attempt to access the TPM at the same time, the TPM device
        will return a busy status; some applications will consider this a fatal
        error instead of retrying the command at a later time. If a vTPM gets an
        error when loading its key, it will currently generate a fresh vTPM image
        (with a new EK, SRK, and blank NVRAM).
    
      Compiling the LINUX domU kernel:
        The domU kernel used by domains with vtpms must include the
        xen-tpmfront.ko driver. It can be built directly into the kernel or as a
        module; however, some features such as IMA require the TPM to be built in
        to the kernel.
    
            CONFIG_TCG_TPM=y
            CONFIG_TCG_XEN=y
    
    VTPM MANAGER SETUP
      Manager disk image setup:
        The vTPM Manager requires a disk image to store its encrypted data. The
        image does not require a filesystem and can live anywhere on the host
        disk. The image is not large; the Xen 4.5 vtpmmgr is limited to using the
        first 2MB of the image but can support more than 20,000 vTPMs.
    
      Manager config file:
        The vTPM Manager domain (vtpmmgr-stubdom) must be started like any other
        Xen virtual machine and requires a config file. The manager requires a
        disk image for storage and permission to access the hardware memory pages
        for the TPM. The disk must be presented as "hda", and the TPM memory pages
        are passed using the iomem configuration parameter. The TPM TIS uses 5
        pages of IO memory (one per locality) that start at physical address
        0xfed40000. By default, the TPM manager uses locality 0 (so only the page
        at 0xfed40 is needed); this can be changed on the domain's command line.
        For full functionality in deep quotes, using locality 2 is required to
        manipulate PCR 20-22.
    
      Starting and stopping the manager:
        The vTPM manager should be started at boot; you may wish to create an init
        script to do this. If a domain builder is used, the TPM Manager should be
        started by the domain builder to minimize the trusted computing base for
        the vTPM manager's secrets.
    
        Once initialization is complete you should see the following:
    
            INFO[VTPM]: Waiting for commands from vTPM's:
    
        The TPM Manager does not respond to shutdown requests; use the destroy
        command to shut it down.
    
    VTPM AND LINUX PVM SETUP
      vTPM disk image setup:
        The vTPM requires a disk image to store its persistent data (RSA keys,
        NVRAM, etc). The image does not require a filesystem. The image does not
        need to be large; 2 Mb should be sufficient.
    
      vTPM config file:
        The vTPM domain requires a configuration file like any other domain. The
        vTPM requires a disk image for storage and a TPM frontend driver to
        communicate with the manager. You are required to generate a uuid for this
        vtpm, which is specified on the "vtpm=" line that describes its connection
        to the vTPM Manager. The uuidgen application may be used to generate a
        uuid, or one from the output of the "manage-vtpmmgr.pl vtpm-add" command
        may be used to create a vTPM belonging to a specific group.
    
        If you wish to clear the vTPM data you can either recreate the disk image
        or change the uuid.
    
      Linux Guest config file:
        The Linux guest config file needs to be modified to include the Linux
        tpmfront driver. Add the following line:
    
            vtpm=["backend=domu-vtpm"]
    
        Currently only Linux guests are supported (PV or HVM with PV drivers).
    
        While attaching a vTPM after a guest is booted (using xl vtpm-attach) is
        supported, the attached vTPM will not have a record of the boot of the
        attached guest. Furthermore, if the vTPM has been freshly created, a
        malicious guest could then extend any values into PCRs, potentially
        forging its boot configuration. Attaching a vTPM to a running domain
        should only be used for trusted domains or when measurements have already
        been sent to the vTPM from another source.
    
      Using the vTPM in the guest:
        If xen-tpmfront was compiled as a module, it must be loaded it in the
        guest.
    
            # modprobe xen-tpmfront
    
        After the Linux domain boots and the xen-tpmfront driver is loaded, you
        should see the following on the vtpm console:
    
            Info: VTPM attached to Frontend X/Y
    
        You can quickly test the vTPM by using the sysfs interface:
    
            # cat /sys/devices/vtpm-0/pubek
            # cat /sys/devices/vtpm-0/pcrs
    
        If you have trousers and tpm_tools installed on the guest, the tpm_version
        command should return the following:
    
        The version command should return the following:
    
            TPM 1.2 Version Info:
            Chip Version:        1.2.0.7
            Spec Level:          2
            Errata Revision:     1
            TPM Vendor ID:       ETHZ
            TPM Version:         01010000
            Manufacturer Info:   4554485a
    
        You should also see the command being sent to the vtpm console as well as
        the vtpm saving its state. You should see the vtpm key being encrypted and
        stored on the vtpmmgr console.
    
        You may wish to write a script to start your vtpm and guest together and
        to destroy the vtpm when the guest shuts down.
    
    INTEGRATION WITH PV-GRUB
        The vTPM currently starts up with all PCRs set to their default values
        (all zeros for the lower 16). This means that any decisions about the
        trustworthiness of the created domain must be made based on the
        environment that created the vTPM and the domU; for example, a system that
        only constructs images using a trusted configuration and guest kernel be
        able to provide guarantees about the guests and any measurements done that
        kernel (such as the IMA TCB log). Guests wishing to use a custom kernel in
        such a secure environment are often started using the pv-grub bootloader
        as the kernel, which then can load the untrusted kernel without needing to
        parse an untrusted filesystem and kernel in dom0. If the pv-grub stub
        domain succeeds in connecting to a vTPM, it will extend the hash of the
        kernel that it boots into PCR #4, and will extend the command line and
        initrd into PCR #5 before booting so that a domU booted in this way can
        attest to its early boot state.
    
    MORE INFORMATION
        See <xen-vtpmmgr(7)> for more details about how the manager domain works,
        how to use it, and its command line parameters.
    
    VTPM DOMAIN OPERATION
        The vtpm-stubdom is a mini-OS domain that emulates a TPM for the guest OS
        to use. It is a small wrapper around the Berlios TPM emulator version
        0.7.4. Commands are passed from the linux guest via the mini-os TPM
        backend driver. vTPM data is encrypted and stored via a disk image
        provided to the virtual machine. The key used to encrypt the data along
        with a hash of the vTPM's data is sent to the vTPM manager for secure
        storage and later retrieval. The vTPM domain communicates with the manager
        using a mini-os tpm front/back device pair.
    
    VTPM DOMAIN COMMAND LINE ARGUMENTS
        Command line arguments are passed to the domain via the 'extra' parameter
        in the VM config file. Each parameter is separated by white space. For
        example:
    
            extra="foo=bar baz"
    
      List of Arguments:
        loglevel=<LOG>
            Controls the amount of logging printed to the console. The possible
            values for <LOG> are:
    
            *   error
    
            *   info (default)
    
            *   debug
    
        clear
            Start the Berlios emulator in "clear" mode. (default)
    
        save
            Start the Berlios emulator in "save" mode.
    
        deactivated
            Start the Berlios emulator in "deactivated" mode. See the Berlios TPM
            emulator documentation for details about the startup mode. For all
            normal use, always use clear which is the default. You should not need
            to specify any of these.
    
        maintcmds=<1|0>
            Enable to disable the TPM maintenance commands. These commands are
            used by tpm manufacturers and thus open a security hole. They are
            disabled by default.
    
        hwinitpcr=<PCRSPEC>
            Initialize the virtual Platform Configuration Registers (PCRs) with
            PCR values from the hardware TPM. Each pcr specified by <PCRSPEC> will
            be initialized with the value of that same PCR in TPM once at startup.
            By default all PCRs are zero initialized. Possible values of <PCRSPEC>
            are:
    
            *   all: copy all pcrs
    
            *   none: copy no pcrs (default)
    
            *   <N>: copy pcr n
    
            *   <X-Y>: copy pcrs x to y (inclusive)
    
            These can also be combined by comma separation, for example:
            "hwinitpcrs=5,12-16" will copy pcrs 5, 12, 13, 14, 15, and 16.
    
    REFERENCES
        Berlios TPM Emulator: <http://tpm-emulator.berlios.de/>
    

Log in to reply
 

© Lightnetics 2024