Re: [PATCH v5.1 01/12] mini-os/tpm{back, front}: Change shared page ABI

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

On 04/11/2013 11:22 AM, Ian Campbell wrote:
> On Thu, 2013-04-11 at 16:10 +0100, Daniel De Graaf wrote:
>> On 04/11/2013 10:27 AM, Ian Campbell wrote:
>>> On Fri, 2013-03-22 at 22:30 +0000, Daniel De Graaf wrote:
>>>>
>>>> +struct vtpm_shared_page {
>>>> +    uint32_t length;         /* request/response length in bytes */
>>>
>>> The data is inline immediately after this struct? How does it interact
>>> with the extra_pages stuff?
>>
>> The data follows immediately after the extra_pages array whose size is
>> visible in nr_extra_pages. The current code only supports skipping the
>> right number of bytes if this array is filled in, it doesn't actually
>> read or write the grant IDs.
>
> Please can we get a comment about this in the header? e.g. netif.h says:
> /*
>   * This is the 'wire' format for packets:
>   *  Request 1: netif_tx_request -- NETTXF_* (any flags)
>   * [Request 2: netif_tx_extra]  (only if request 1 has NETTXF_extra_info)
>   * [Request 3: netif_tx_extra]  (only if request 2 has XEN_NETIF_EXTRA_MORE)
>   *  Request 4: netif_tx_request -- NETTXF_more_data
>   *  Request 5: netif_tx_request -- NETTXF_more_data
>   *  ...
>   *  Request N: netif_tx_request -- 0
>   */
>
> An equivalent diagram for tpm would be useful.

OK

>>>> +
>>>> +    uint8_t state;           /* enum vtpm_state */
>>>> +    uint8_t locality;        /* for the current request */
>>>
>>> I've had a look at the 7/12 and 10/12 and I'm still not sure how this
>>> byte is used -- it's looked up in the XSM label as a string but how does
>>> it become a uint8_t agreed by both the front and backend?
>>
>> The frontend can set this byte (the existing Linux patch does not do so,
>> but the v2 includes a sysfs attribute that allows you to set the locality
>> for a given request). In the hardware TPM 1.2 interface, the TPM exposes
>> a distinct MMIO page for each locality and the chipset provides limits on
>> when writes to locality 4 (and possibly 3) are allowed.
>
> These localities are defined by the TPM spec?

Yes, although the fact that 3 and 4 are special is specific to the PC Client
specification - http://www.trustedcomputinggroup.org/resources/pc_client_work_group_pc_client_specific_tpm_interface_specification_tis

While localities are currently restricted to the values 0-4, a future spec
release will allow virtual TPMs to define and use higher locality numbers,
although the locality number will always be limited to a single byte due to
existing data structure sizes.

>>> Could we perhaps get a few more words on the protocol in general? Or
>>> have I missed some existing doc?
>>
>> This protocol emulates the request/response behavior of a TPM using a Xen
>> shared memory interface. All interaction with the TPM is at the direction
>> of the frontend, since a TPM (hardware or virtual) is a passive device -
>> the backend only processes commands as requested by the frontend.
>>
>> The frontend sends a request to the TPM by populating the shared page with
>> the request packet, changing the state to VTPM_STATE_SUBMIT, and sending
>> and event channel notification. When the backend is finished, it will set
>> the state to VTPM_STATE_FINISH and send an event channel notification.
>>
>> In order to allow long-running commands to be canceled, the frontend can
>> at any time change the state to VTPM_STATE_CANCEL and send a notification.
>> The TPM can either finish the command (changing state to VTPM_STATE_FINISH)
>> or can cancel the command and change the state to VTPM_STATE_IDLE. The TPM
>> can also change the state to VTPM_STATE_IDLE instead of VTPM_STATE_FINISH
>> if another reason for cancellation is required - for example, a physical
>> TPM may cancel a command if the interface is seized by another locality.
>
> Understood, thanks.
>
>> If you would like this description in the Xen tree, where is the best place
>> to locate it? The existing docs/misc/vtpm.txt is more focused on the use of
>> the TPM domains, not the protocol, but an additional section could be added
>> for documenting the Xen protocol.
>
> Having all the info you gave in this mail in the vtpm.h header would be
> good.

OK

>>> What is the format of the payload, is it defined by some independent TPM
>>> standard?
>>
>> The payload is a TPM packet as defined by the TPM specification:
>> http://www.trustedcomputinggroup.org/resources/tpm_main_specification
>> (part 3 defines the packet format).
>
> Can you add this link to the header please?

Yep.

>>
>>>> +    uint8_t pad;             /* should be zero */
>>>> +
>>>> +    uint8_t nr_extra_pages;  /* extra pages for long packets; may be zero */
>>>> +    uint32_t extra_pages[0]; /* grant IDs; length is actually nr_extra_pages */
>>>
>>> Not actually used AFAICT? Future expansion I presume?
>>
>> Yes. While normally TPM packets are all under 4000 bytes, the specification allows
>> larger packets (the TPM itself defines the maximum), and future versions of the
>> TPM specification that do not limit the TPM to 2048-bit RSA keys may require using
>> larger packets. Some commands (such as GetRandom) can produce packets of arbitrary
>> size, although it is reasonable for an implementation to limit what it returns so
>> this is not a problem for the vTPM.
>
> OK.  Thanks,
>
> Ian.
>

I'll send v5.2 soon.

-- 
Daniel De Graaf
National Security Agency