"Kevin O'Connor" <kevin@koconnor.net> wrote on 02/01/2016 04:50:22 PM:

>
> On Fri, Jan 22, 2016 at 03:27:28PM -0500, Stefan Berger wrote:
> > "Kevin O'Connor" <kevin@koconnor.net> wrote on 01/21/2016 05:37:29 PM:
> > > Thanks Stefan.  In general it looks good to me.  I have a few
> > > comments, which I'll send separately.  All of my comments could be
> > > addressed after committing this series if desired.
> >
> > I can address those comments and repost a V2 with the 10th patch adding
> > the part for the logging.
>
> Hi Stefan.  Sorry for the delay in responding.  I have a couple of
> comments on the new patch series which I will respond with separately.
>
> > > How does one test and/or use this support?  Does QEMU have support, or
> > > is there hardware available on coreboot with the tpm2 hardware?
> >
> > I did all the testing of these patches with the vTPM with CUSE interface
> > integrated into QEMU. Unfortunately the vTPM-QEMU integration train seems
> > a wreck now following comments on QEMU mailing list. So, I don't know of
> > any TPM 2 hardware out there, less so hardware where coreboot runs. So
> > that's probably currently the number one problem.
>
> Normally, I prefer to wait until upstream has committed the equivalent
> patches.  I think there is some leeway here, however, because this
> series could be considered as adding support for additional hardware.
>
> That said, if you don't know of any TPM2 hardware that is shipping, it
> does raise the possibility that the specs might change by the time
> actual hardware does ship.  What is your feel for the trade-off
> between merging now and merging after actual implementations exist?

TPM 2 is a published TCG and ISO/IED 11889:2015 standard now.

http://www.trustedcomputinggroup.org/resources/tpm_library_specification

Devices with TPM 2 are also shipping:

http://store.hp.com/us/en/pdp/hp-elitebook-folio-1020-g1-notebook-pc-%28energy-star%29-p-l4a53ut-aba--1
http://www.notebookcheck.net/Dell-XPS-13-Ultrabook-Review.136793.0.html



>
> > You know the TPM 1.2 PC BIOS specification, right? I think we can say that
> > many of the functions implemented in this series for TPM 2 are necessary
> > because of how it's done for TPM 1.2 as well as properties of the TPM 2
> > device. This includes the TPM initialization, S3 support, setting of
> > timeouts, menu items, etc. The problem with TPM 2 is that there's no
> > official spec for TPM 2 for a BIOS. So it's not quite clear to me how much
> > leeway we have to go about this in the areas of ACPI tables for logging
> > and the API. Regarding these topics:
> >
> > ACPI tables for logging: The (U)EFI specification for TPM 2 don't require
> > a TCPA table with the logging area because there seems to be an API for
> > the OS for retrieving the log. UEFI seems to log into just some buffer,
> > not connected to any ACPI table. For the BIOS we would still need that
> > TCPA table. QEMU currently provides that. The Linux kernel (and all other
> > OSes -- uuuh) would then have to allow a TCPA table for logging for TPM 2
> > even though we cannot point to a spec for that. Not sure whether we can
> > create a standard for this little gap here...
>
> It sounds like the creators of the spec assumed only EFI machines
> would have a TPM2 device.  Unless there is evidence that OSes will
> accept the ACPI/TCPA table in the new format, I'd be inclined to leave
> it in the old format.

I think the format goes with the TPM 2. We should be able to log into the TCPA table. It wouldn't make sense to come up with a new table and the logging format should be TPM 2 specific.

>
> > BIOS API: Some functions pass the entry to write into the log via the
> > function directly. Patch 10 handles that and transforms that entry into
> > the log entry format as required for TPM 1.2 or TPM 2 (log entries are
> > differently formatted for TPM 1.2 and for TPM 2). So the only remaining
> > problem I know of is the function that allows one to pass TPM commands
> > through to the TPM. This may end up causing problems in the application if
> > it was written for TPM 1.2 and now there's a TPM 2 running underneath,
> > which doesn't understand the TPM 1.2 commands. I would say this is likely
> > the smaller of the problems also considering that there are not many
> > applications out there that use that API call. Possibility to just shut
> > down that function call is certainly there.
>
> I'd say returning an error code for pass-through command requests is
> the safest solution.

TPM 1.2 and TPM 2 commands all differ in the tag field. We could filter by that and return an error if the tag is not for the underlying TPM.

   Stefan



>
> -Kevin
>