Features/TPM
Trusted Platform Module Support Phase I
Some background:
The Trusted Platform Module (TPM) is a crypto device that has been built into many modern servers, laptops and even handheld devices. Operating Systems have been extended with device driver support for the TPM. On Linux the device can be used via /dev/tpm0.
Internally the TPM can be borken up into two parts. The upper part is the memory mapped IO (MMIO) interface. For the TPM 1.2 the Trusted Computing Group (TCG) has defined a standard interface called TPM Interface Standard (TIS) whose registers are in the 0x FED4 0000 - 0xFED4 4FFF address range. The specs for this interface can be found here.
The lower part of the device would then be the core TPM that processes the TPM commands (aka 'ordinals'). More than 100 different commands have been defined for this device. Specs for the ordinals can be found here:
The TIS interface collects the request messages and sends the completed requests to the TPM, the TPM then processes the command and sends the result message to the TIS which then may raise an interrupt to notify the driver to pick up the response. Processing commands may range from less than a second to more than a minute, depending on what kind of operation the TPM is supposed to perform. Crypto operations, such as for example the generation of a 2048 bit RSA key, may take some time.
In several ways the TPM is different than many of the other devices found in a computer: - There is explicit firmware (BIOS/UEFI/...) support for the TPM.
- The BIOS sends a command sequence to the TPM. That same command sequence cannot be sent to the TPM again until the machine is rebooted. - The BIOS allows the TPM to be enabled/disable or activated/deactivated using a menu.
- The TPM is reset by a pulse from the CPU/chipset when the machine reboots. This then allows re-initialization. - The TPM has built-in NVRAM where it stored persistent state. - Persistent State of the TPM comprises:
- Keys: Endorsement Key (typically created during manufacturing), Storage Root Key (SRK), other persisted keys - Owner password (a user can take ownership of the TPM until explicitly released) - counters - internal flags - etc.
Phase I:
For Phase I of TPM integration into QEMU I am proposing the integration of a 'passthrough' driver that enables users to access the host's TPM from within the VM.
Inside a Linux VM for example the usual tpm_tis driver (modprobe tpm_tis) will be enabled talking to an emulated TPM TIS frontend. The TPM TIS will then in turn communicate with /dev/tpm0, implemented in the 'passthrough' backend. Only one VM on a physical system will be able to use the single host TPM device. Since the persistent state of the TPM (ownership information, persisted keys etc.) as well as the volatile state (state of the Platform Configuration Registers (PCRs), loaded keys) cannot migrate along with the VM, migration of a VM using this 'passthrough' driver will be disabled.
In the 2nd phase of TPM integration each QEMU instance will have access to its own private TPM. This emulated device will then behave like a hardware TPM and require initialization by the firmware, such as for example SeaBIOS. This step will require the implementation of (v)NVRAM support for enabling persistent state to be saved.