On 06/27/17 18:12, Stefan Berger wrote: > On 06/14/2017 09:51 AM, Laszlo Ersek wrote: >> Hi Stefan, >> >> the MAINTAINERS file doesn't seem to cover any of the TPM-related files >> in the tree: >> >> backends/tpm.c >> hw/tpm/ >> include/hw/acpi/tpm.h >> include/sysemu/tpm* >> tpm.c >> >> but I have a gut feeling that you are semi-officially maintaining TPM >> anyway, so I'm going to ask you. :) >> >> Can you please write a document, to be placed under docs/specs/, that >> describes the TPM device from a guest perspective, also explaining how >> the guest-visible bits are connected to (current) TPM backend(s)? >> >> The document wouldn't have to be very long; I think all standardized >> interfaces could be mentioned by reference only (by spec names and >> locations). The document should however describe any QEMU specifics, and >> how the relevant specs are brought together in the implementation. >> >> Some text files I'm familiar with and can recommend as examples: >> - docs/specs/fw_cfg.txt >> - docs/specs/pvpanic.txt >> - docs/specs/vmgenid.txt >> >> (There may be more and/or better examples of course.) >> >> This document should be the starting point for developers that want to >> support QEMU's TPM(s) in guest firmware that is different from SeaBIOS. >> (You've been maintaining the related SeaBIOS feature.) >> >> Would you be willing to author such a design document? > > Here's what I have so far with pointers to TCG specs. Does that go in > the right direction? > > > QEMU TPM Device > =============== > > = Guest-side Hardware Interface = > > The QEMU TPM emulation implements a TPM TIS hardware interface following > the Trusted Computing Group's specification "TCG PC Client Specific TPM > Interface Specification (TIS)", Specifcation Version 1.3, 21 March 2013. > This specification, or a later version of it, can be accessed from the > following URL: > > https://trustedcomputinggroup.org/pc-client-work-group-pc-client-specific-tpm-interface-specification-tis/ > > > The TIS interface makes a memory mapped IO region in the area 0xfed40000 - > 0xfed44fff available to the guest operating system. > > = ACPI Interface = > > The TPM device is defined with ACPI ID "PNP0C31". QEMU builds a SSDT and > passes > it into the guest through the fw_cfg device. The device description > contains > the base address of the TIS interface 0xfed40000 and the size of the
Double space before "0xfed40000". > MMIO area > (0x5000). In case a TPM2 is used by QEMU, a TPM2 ACPI table is also > provided. The > device is described to be used in polling mode rather than interrupt > mode primarily > because no unused IRQ could be found. > > To support measurements logs to be written by the firmware, e.g. > SeaBIOS, a TCPA > table is implemented. This table provides a 64kb buffer where the > firmware can > write its log into. Does the TCPA table depend on TPM1 vs. TPM2? > > The TCPA and TPM2 ACPI tables follow the Trusted Computing Group > specification > "TCG ACPI Specification" Family "1.2" and "2.0", Level 00 Revision > 00.37. This > specification, or a later version of it, can be accessed from the following > URL: > > https://trustedcomputinggroup.org/tcg-acpi-specification/ > > > = TPM backend devices = > > The TPM implementation is split into two parts. The one part is the > hardware > interface, such as the TPM TIS interface described earlier, and the TPM > backend > interface. The last sentence here is a bit hard to understand. Can we use frontend/backend language? (Already used below, so that's great.) > The backend interfaces implement the interaction with a TPM > device, > which may be a physical or an emulated device. The split between the front- > and backend devices allows a frontend to be connected with any available > backend. This enables the TIS interface to be used with the passthrough > backend > or the (future) swtpm backend. > > > == The QEMU TPM passthrough device == > > In case QEMU is run on Linux as the host operating system it is possible to > make the hardware TPM device available to a single QEMU guest. In this > case the > user must make sure that no other program is using the device, e.g., > /dev/tpm0, > before trying to start QEMU with it. > > The passthrough driver uses the host's TPM device for sending TPM commands > and receiving responses from. Besides that it accesses the TPM device's > sysfs > entry for support of command cancellation. Since none of the state of a > hardware > TPM can be migrated between hosts, virtual machine migration is disabled > when > the TPM passthrough driver is used. > > Since the host's TPM device will already be initialize by the host's > firmware, certain I think this line is too long (87 chars) -- I think we should wrap at 79 chars or so. > commands, e.g. TPM_Startup(), sent by the virtual firmware for device > initialization > will fail. In this case the firmware should simply not use the TPM. > > Sharing the device with the host is generally not a recommended usage > scenario > for a TPM device. The primary reason for this is that two operating > systems can then > access the device's single set of resources, such as platform configuration > registers (PCRs), that applications are not expecting to share. Looks great to me, thank you! Two requests in addition to the above remarks: - can you provide command line options / examples wherever appropriate? - can you list the pathnames of the source files that currently implement frontend / backend / ACPI / passthrough, as appropriate? (I think the next version should be posted as a first class PATCH, for wider review.) Thank you! Laszlo