[Qemu-devel] TPM status

[Qemu-devel] TPM status

[Laszlo Ersek]

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?

Thank you,
Laszlo

Re: [Qemu-devel] TPM status

[Stefan Berger]

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?

I'll look into that. Give me some time...

    Stefan


>
> Thank you,
> Laszlo
>

Re: [Qemu-devel] TPM status

[Stefan Berger]

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 
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.

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 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
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.


>
> Thank you,
> Laszlo
>

Re: [Qemu-devel] TPM status

[Laszlo Ersek]

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

Re: [Qemu-devel] TPM status

[Stefan Berger]

On 06/27/2017 12:32 PM, Laszlo Ersek wrote:
>
> Looks great to me, thank you!
>
> Two requests in addition to the above remarks:
> - can you provide command line options / examples wherever appropriate?

I didn't add it because we describe that on this page here:

http://download.qemu.org/qemu-doc.html


"To create a passthrough TPM use the following two options:

-tpmdev passthrough,id=tpm0 -device tpm-tis,tpmdev=tpm0"


   Stefan

Re: [Qemu-devel] TPM status

[Laszlo Ersek]

On 06/29/17 21:31, Stefan Berger wrote:
> On 06/27/2017 12:32 PM, Laszlo Ersek wrote:
>>
>> Looks great to me, thank you!
>>
>> Two requests in addition to the above remarks:
>> - can you provide command line options / examples wherever appropriate?
> 
> I didn't add it because we describe that on this page here:
> 
> http://download.qemu.org/qemu-doc.html
> 
> 
> "To create a passthrough TPM use the following two options:
> 
> -tpmdev passthrough,id=tpm0 -device tpm-tis,tpmdev=tpm0"

Yes, I saw that in the manual. The manual is huge, and personally I'd
prefer either an embedded example or a more targeted reference.

At least in "docs/pcie.txt", Marcel added a whole bunch of command line
snippets, and it is *very* useful (to me anyway).
"docs/specs/fw_cfg.txt" also talks about the command line under
"Externally Provided Items".

Thanks for considering it,
Laszlo

Re: [Qemu-devel] TPM status

[Peter Jones]

On Tue, Jun 27, 2017 at 12:12:50PM -0400, 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 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.

How does this work if we boot with edk2?  Do we get what's described in 
https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf
instead of this interface?  As well as it?  It'd be good to have some
text about this here.

-- 
  Peter

Re: [Qemu-devel] TPM status

[Laszlo Ersek]

On 06/28/17 17:22, Peter Jones wrote:
> On Tue, Jun 27, 2017 at 12:12:50PM -0400, 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 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.
> 
> How does this work if we boot with edk2?

My expectation is that it doesn't work at all, without doing some OVMF
platform enablement first. (See
<https://bugzilla.tianocore.org/show_bug.cgi?id=594>.) My plan is to use
Stefan's document as a starting point for the edk2 / OVMF investigation
-- one known and one unknown are better than two unknowns (to me).

> Do we get what's described in 
> https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf
> instead of this interface?  As well as it?  It'd be good to have some
> text about this here.

I don't think that Stefan has spent any time on EFI enablement, so this
part of the document will have to be written later, once there is any
EFI-related functionality we can document. (I expect.)

Thanks,
Laszlo

Re: [Qemu-devel] TPM status

[Stefan Berger]

On 06/28/2017 12:44 PM, Laszlo Ersek wrote:
> On 06/28/17 17:22, Peter Jones wrote:
>> On Tue, Jun 27, 2017 at 12:12:50PM -0400, 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 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.
>> How does this work if we boot with edk2?
> My expectation is that it doesn't work at all, without doing some OVMF
> platform enablement first. (See
> <https://bugzilla.tianocore.org/show_bug.cgi?id=594>.) My plan is to use
> Stefan's document as a starting point for the edk2 / OVMF investigation
> -- one known and one unknown are better than two unknowns (to me).
>> Do we get what's described in
>> https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf
>> instead of this interface?  As well as it?  It'd be good to have some
>> text about this here.
> I don't think that Stefan has spent any time on EFI enablement, so this
> part of the document will have to be written later, once there is any
> EFI-related functionality we can document. (I expect.)

Right, I did not spend any time on EFI. I suppose the ACPI tables going 
to a BIOS are also useful for EFI.

For BIOS there is unfortunately only a spec for TPM 1.2, none anymore 
for TPM2, at least back then when I last looked for it. So I ended up 
passing that TCPA table that has the pointer for the logging area also 
in case of a TPM 2. So SeaBIOS writes its log to it in both cases, 
following the TPM 2 format form the EFI specs for the entries. The Linux 
driver in the meantime has modified the code so  that it doesn't show 
the log anymore in case of TPM 2 :-( . I think the above referenced 
specs would explain how the logging area is to be allocated. My guess is 
that after detecting the presence of a TPM 2 (for which there is also a 
TPM2 ACPI table passed, so maybe that can be used as an indicator) one 
would malloc() the logging area and then proceed similar to how the BIOS 
does. The difference to a BIOS is that EFI has an API for getting to 
that log iirc.

     Stefan

Re: [Qemu-devel] TPM status

[Laszlo Ersek]

On 06/28/17 22:57, Stefan Berger wrote:
> On 06/28/2017 12:44 PM, Laszlo Ersek wrote:
>> On 06/28/17 17:22, Peter Jones wrote:
>>> On Tue, Jun 27, 2017 at 12:12:50PM -0400, 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 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.
>>> How does this work if we boot with edk2?
>> My expectation is that it doesn't work at all, without doing some OVMF
>> platform enablement first. (See
>> <https://bugzilla.tianocore.org/show_bug.cgi?id=594>.) My plan is to use
>> Stefan's document as a starting point for the edk2 / OVMF investigation
>> -- one known and one unknown are better than two unknowns (to me).
>>> Do we get what's described in
>>> https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf
>>>
>>> instead of this interface?  As well as it?  It'd be good to have some
>>> text about this here.
>> I don't think that Stefan has spent any time on EFI enablement, so this
>> part of the document will have to be written later, once there is any
>> EFI-related functionality we can document. (I expect.)
> 
> Right, I did not spend any time on EFI. I suppose the ACPI tables going
> to a BIOS are also useful for EFI.
> 
> For BIOS there is unfortunately only a spec for TPM 1.2, none anymore
> for TPM2, at least back then when I last looked for it. So I ended up
> passing that TCPA table that has the pointer for the logging area also
> in case of a TPM 2. So SeaBIOS writes its log to it in both cases,
> following the TPM 2 format form the EFI specs for the entries. The Linux
> driver in the meantime has modified the code so  that it doesn't show
> the log anymore in case of TPM 2 :-( . I think the above referenced
> specs would explain how the logging area is to be allocated. My guess is
> that after detecting the presence of a TPM 2 (for which there is also a
> TPM2 ACPI table passed, so maybe that can be used as an indicator) one
> would malloc() the logging area and then proceed similar to how the BIOS
> does. The difference to a BIOS is that EFI has an API for getting to
> that log iirc.

I haven't checked yet, but my worry is that the TPM drivers in edk2 will
want to install the ACPI tables related to the TPM device /
infrastructure themselves. If that's the case, we'll either have to
modify QEMU not to produce those tables in the ACPI payload, despite
exposing a TPM device to the guest -- clearly this will take another
command line option, or an extension to one --, or else the TPM drivers
in edk2 will have to be convinced to cope with the ACPI tables
pre-installed, by some other firmware module. Again, I'm not sure if
either of these will be necessary, but if one is, then the former looks
way more feasible to me. The TPM drivers in edk2 could reasonably argue
that on a physical platform they "own" the TPM device, along with all
ACPI tables related to it. We'll see.

Thanks
Laszlo

Re: [Qemu-devel] TPM status

[Javier Martinez Canillas]

Hello Stefan,

On 06/28/2017 10:57 PM, Stefan Berger wrote:
> On 06/28/2017 12:44 PM, Laszlo Ersek wrote:
>> On 06/28/17 17:22, Peter Jones wrote:
>>> On Tue, Jun 27, 2017 at 12:12:50PM -0400, Stefan Berger wrote:

[snip]

>>>>
>>>> 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.
>>> How does this work if we boot with edk2?
>> My expectation is that it doesn't work at all, without doing some OVMF
>> platform enablement first. (See
>> <https://bugzilla.tianocore.org/show_bug.cgi?id=594>.) My plan is to use
>> Stefan's document as a starting point for the edk2 / OVMF investigation
>> -- one known and one unknown are better than two unknowns (to me).
>>> Do we get what's described in
>>> https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf
>>> instead of this interface?  As well as it?  It'd be good to have some
>>> text about this here.
>> I don't think that Stefan has spent any time on EFI enablement, so this
>> part of the document will have to be written later, once there is any
>> EFI-related functionality we can document. (I expect.)
> 
> Right, I did not spend any time on EFI. I suppose the ACPI tables going to a BIOS are also useful for EFI.
> 
> For BIOS there is unfortunately only a spec for TPM 1.2, none anymore for
> TPM2, at least back then when I last looked for it. So I ended up passing
> that TCPA table that has the pointer for the logging area also in case of
> a TPM 2. So SeaBIOS writes its log to it in both cases, following the TPM 2

But this isn't correct from a TPM2 pov, right? Because the TPM2 spec says
that the ACPI table that contains the TPM2.0 event logs is the TPM2 table.

So instead the LASA field in the passed TPM2 ACPI table should point to the
allocated buffer used by the firmware to store the event logs.

> format form the EFI specs for the entries. The Linux driver in the meantime
> has modified the code so  that it doesn't show the log anymore in case of
> TPM 2 :-( . I think the above referenced specs would explain how the logging

Do you mean that in the past Linux exposed the securityfs files with the event
logs for TPM2 chips as well? My understanding is that Linux does the correct
thing now, since as mentioned the TCPA table should only be used for TPM1.2.

There are patches posted to add Linux support to read the event logs for TPM2
chips but from the TPM2 ACPI table. I see that hose haven't landed yet though:

https://patchwork.kernel.org/project/tpmdd-devel/list/?submitter=7143

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

Re: [Qemu-devel] TPM status

[Stefan Berger]

On 06/29/2017 10:07 AM, Javier Martinez Canillas wrote:
> Hello Stefan,
>
> On 06/28/2017 10:57 PM, Stefan Berger wrote:
>> On 06/28/2017 12:44 PM, Laszlo Ersek wrote:
>>> On 06/28/17 17:22, Peter Jones wrote:
>>>> On Tue, Jun 27, 2017 at 12:12:50PM -0400, Stefan Berger wrote:
> [snip]
>
>>>>> 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.
>>>> How does this work if we boot with edk2?
>>> My expectation is that it doesn't work at all, without doing some OVMF
>>> platform enablement first. (See
>>> <https://bugzilla.tianocore.org/show_bug.cgi?id=594>.) My plan is to use
>>> Stefan's document as a starting point for the edk2 / OVMF investigation
>>> -- one known and one unknown are better than two unknowns (to me).
>>>> Do we get what's described in
>>>> https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf
>>>> instead of this interface?  As well as it?  It'd be good to have some
>>>> text about this here.
>>> I don't think that Stefan has spent any time on EFI enablement, so this
>>> part of the document will have to be written later, once there is any
>>> EFI-related functionality we can document. (I expect.)
>> Right, I did not spend any time on EFI. I suppose the ACPI tables going to a BIOS are also useful for EFI.
>>
>> For BIOS there is unfortunately only a spec for TPM 1.2, none anymore for
>> TPM2, at least back then when I last looked for it. So I ended up passing
>> that TCPA table that has the pointer for the logging area also in case of
>> a TPM 2. So SeaBIOS writes its log to it in both cases, following the TPM 2
> But this isn't correct from a TPM2 pov, right? Because the TPM2 spec says
> that the ACPI table that contains the TPM2.0 event logs is the TPM2 table.

The problem is the lack of specs for BIOS to support TPM. I don't see 
how the TPM2 could hold the log pointer. I am looking at section 7.3 in 
this document here:

https://www.trustedcomputinggroup.org/wp-content/uploads/TCG_ACPIGeneralSpecification_1-10_0-37-Published.pdf


>
> So instead the LASA field in the passed TPM2 ACPI table should point to the
> allocated buffer used by the firmware to store the event logs.

I only see LAML and LASA for TCPA ACPI table (sections 7.1.2 & 7.2.2),  
which seems to only be valid for TPM 1.2.


>> format form the EFI specs for the entries. The Linux driver in the meantime
>> has modified the code so  that it doesn't show the log anymore in case of
>> TPM 2 :-( . I think the above referenced specs would explain how the logging
> Do you mean that in the past Linux exposed the securityfs files with the event
> logs for TPM2 chips as well? My understanding is that Linux does the correct
> thing now, since as mentioned the TCPA table should only be used for TPM1.2.

There may have been a version or two of the driver that did that, yes.

This version has this check:

http://elixir.free-electrons.com/linux/v4.11.8/source/drivers/char/tpm/tpm_acpi.c#L57

This version does not have this check:

http://elixir.free-electrons.com/linux/v4.10.17/source/drivers/char/tpm/tpm_acpi.c



>
> There are patches posted to add Linux support to read the event logs for TPM2
> chips but from the TPM2 ACPI table. I see that hose haven't landed yet though:
>
> https://patchwork.kernel.org/project/tpmdd-devel/list/?submitter=7143

Aha, so I see this person is following some draft spec that isn't 
referenced via above page, yet.

"Latest draft of TPM 2 ACPI specification added TCG log start/length
to the TPM2 ACPI table.  So Linux kernel can now read it without
having to get involved with boot loader, same way TPM1/TCPA tables
work."

https://patchwork.kernel.org/patch/9651005/

> Best regards,

Re: [Qemu-devel] TPM status

[Javier Martinez Canillas]

Hello Stefan,

Thanks a lot for the summary, it's very informative. I've a question below.

On 06/27/2017 06:12 PM, Stefan Berger wrote:

> 
> 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.
>

Besides the TIS interface, the TPM2.0 spec defines a CRB (Command Response
Buffer Interface) as described in the "TCG PC Client Platform TPM Profile
(PTP) Specification Family 2.0, Level 00 Revision 00.43, January 26, 2015"

https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2-0-v43-150126.pdf

> 
> = 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 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.

So we will need another TPM interface that implements the CRB interface? I
have a machine with the Intel PTT TPM2.0 (firmware-based implemented in ME)
that uses this CRB interface instead of TIS1.2 + cancel, so libvirt fails:

Error starting domain: internal error: No usable sysfs TPM cancel file could be found

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 124, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1479, in startup
    self._backend.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1039, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: No usable sysfs TPM cancel file could be found

The Linux kernel exposes either a TIS or CRB interface depending on what is
filled in the TPM2 ACPI table "Start Method" field as specified in "TCG ACPI
Specification Family 1.2 and 2.0 Version 1.2, Revision 8 February 27, 2017"

https://trustedcomputinggroup.org/wp-content/uploads/TCG_ACPIGeneralSpecification-Family-1.2-and-2.0-Ver1.2-Rev8_public-revie....pdf

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

Re: [Qemu-devel] TPM status

[Stefan Berger]

On 06/29/2017 08:39 AM, Javier Martinez Canillas wrote:
> Hello Stefan,
>
> Thanks a lot for the summary, it's very informative. I've a question below.
>
> On 06/27/2017 06:12 PM, Stefan Berger wrote:
>
>> 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.
>>
> Besides the TIS interface, the TPM2.0 spec defines a CRB (Command Response
> Buffer Interface) as described in the "TCG PC Client Platform TPM Profile
> (PTP) Specification Family 2.0, Level 00 Revision 00.43, January 26, 2015"
>
> https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2-0-v43-150126.pdf
>
>> = 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 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.
> So we will need another TPM interface that implements the CRB interface? I

No. How did you infer that ?

> have a machine with the Intel PTT TPM2.0 (firmware-based implemented in ME)
> that uses this CRB interface instead of TIS1.2 + cancel, so libvirt fails:
>
> Error starting domain: internal error: No usable sysfs TPM cancel file could be found
>
> Traceback (most recent call last):
>    File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
>      callback(asyncjob, *args, **kwargs)
>    File "/usr/share/virt-manager/virtManager/asyncjob.py", line 124, in tmpcb
>      callback(*args, **kwargs)
>    File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn
>      ret = fn(self, *args, **kwargs)
>    File "/usr/share/virt-manager/virtManager/domain.py", line 1479, in startup
>      self._backend.create()
>    File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1039, in create
>      if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
> libvirtError: internal error: No usable sysfs TPM cancel file could be found
>
> The Linux kernel exposes either a TIS or CRB interface depending on what is
> filled in the TPM2 ACPI table "Start Method" field as specified in "TCG ACPI
> Specification Family 1.2 and 2.0 Version 1.2, Revision 8 February 27, 2017"
>
> https://trustedcomputinggroup.org/wp-content/uploads/TCG_ACPIGeneralSpecification-Family-1.2-and-2.0-Ver1.2-Rev8_public-revie....pdf
>
> Best regards,

This will require a patch to libvirt. In case the host has a TPM 2 the 
cancel sysfs entry does not exist and we need to pass /dev/null instead. 
I'll have a look at that.


    Stefan

Re: [Qemu-devel] TPM status

[Javier Martinez Canillas]

On 06/29/2017 06:09 PM, Stefan Berger wrote:
> On 06/29/2017 08:39 AM, Javier Martinez Canillas wrote:

[snip]

>>
>>> = 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 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.
>> So we will need another TPM interface that implements the CRB interface? I
> 
> No. How did you infer that ?
> 

I thought that if the host firmware set the TPM2 Start Method to CRB instead of
TIS1.2+cancel, then the guest would have to use the same interface.

But now with your patch libvirt doesn't complain anymore about a missing cancel
sysfs file and I could access the host TPM2.0 as a pass-through device, even
when the host is using the tpm_crb driver while the guest uses the tpm_tis one.

Sorry for the confusion, I'm just been learning about the TPM and still trying
to make sense of all the different specifications and documents.

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

Re: [Qemu-devel] TPM status

[Stefan Berger]

On 06/29/2017 07:12 PM, Javier Martinez Canillas wrote:
> On 06/29/2017 06:09 PM, Stefan Berger wrote:
>> On 06/29/2017 08:39 AM, Javier Martinez Canillas wrote:
> [snip]
>
>>>> = 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 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.
>>> So we will need another TPM interface that implements the CRB interface? I
>> No. How did you infer that ?
>>
> I thought that if the host firmware set the TPM2 Start Method to CRB instead of
> TIS1.2+cancel, then the guest would have to use the same interface.
>
> But now with your patch libvirt doesn't complain anymore about a missing cancel
> sysfs file and I could access the host TPM2.0 as a pass-through device, even
> when the host is using the tpm_crb driver while the guest uses the tpm_tis one.

For passthrough really only /dev/tpm0 matters. The rest of the interface 
and what interface the host device has doesn't matter, at least not with 
the TPM device.

Regards,
     Stefan