<tt><font size=2>"Kevin O'Connor" <kevin@koconnor.net>
wrote on 02/01/2016 04:50:22 PM:<br></font></tt><br><tt><font size=2>> <br>> On Fri, Jan 22, 2016 at 03:27:28PM -0500, Stefan Berger wrote:<br>> > "Kevin O'Connor" <kevin@koconnor.net> wrote on
01/21/2016 05:37:29 PM:<br>> > > Thanks Stefan.  In general it looks good to me.  I
have a few<br>> > > comments, which I'll send separately.  All of my comments
could be<br>> > > addressed after committing this series if desired.<br>> > <br>> > I can address those comments and repost a V2 with the 10th patch
adding <br>> > the part for the logging.<br>> <br>> Hi Stefan.  Sorry for the delay in responding.  I have a
couple of<br>> comments on the new patch series which I will respond with separately.<br>> <br>> > > How does one test and/or use this support?  Does QEMU
have support, or<br>> > > is there hardware available on coreboot with the tpm2 hardware?<br>> > <br>> > I did all the testing of these patches with the vTPM with CUSE
interface <br>> > integrated into QEMU. Unfortunately the vTPM-QEMU integration
train seems <br>> > a wreck now following comments on QEMU mailing list. So, I don't
know of <br>> > any TPM 2 hardware out there, less so hardware where coreboot
runs. So <br>> > that's probably currently the number one problem.<br>> <br>> Normally, I prefer to wait until upstream has committed the equivalent<br>> patches.  I think there is some leeway here, however, because
this<br>> series could be considered as adding support for additional hardware.<br>> <br>> That said, if you don't know of any TPM2 hardware that is shipping,
it<br>> does raise the possibility that the specs might change by the time<br>> actual hardware does ship.  What is your feel for the trade-off<br>> between merging now and merging after actual implementations exist?</font></tt><br><br><tt><font size=2>TPM 2 is a published TCG and ISO/IED 11889:2015 standard
now.</font></tt><br><br><a href=http://www.trustedcomputinggroup.org/resources/tpm_library_specification><tt><font size=2 color=blue>http://www.trustedcomputinggroup.org/resources/tpm_library_specification</font></tt></a><br><br><tt><font size=2>Devices with TPM 2 are also shipping:</font></tt><br><br><a href="http://store.hp.com/us/en/pdp/hp-elitebook-folio-1020-g1-notebook-pc-%28energy-star%29-p-l4a53ut-aba--1"><tt><font size=2 color=blue>http://store.hp.com/us/en/pdp/hp-elitebook-folio-1020-g1-notebook-pc-%28energy-star%29-p-l4a53ut-aba--1</font></tt></a><br><a href="http://www.notebookcheck.net/Dell-XPS-13-Ultrabook-Review.136793.0.html"><tt><font size=2 color=blue>http://www.notebookcheck.net/Dell-XPS-13-Ultrabook-Review.136793.0.html</font></tt></a><br><br><br><tt><font size=2><br>> <br>> > You know the TPM 1.2 PC BIOS specification, right? I think we
can say that <br>> > many of the functions implemented in this series for TPM 2 are
necessary <br>> > because of how it's done for TPM 1.2 as well as properties of
the TPM 2 <br>> > device. This includes the TPM initialization, S3 support, setting
of <br>> > timeouts, menu items, etc. The problem with TPM 2 is that there's
no <br>> > official spec for TPM 2 for a BIOS. So it's not quite clear to
me how much <br>> > leeway we have to go about this in the areas of ACPI tables for
logging <br>> > and the API. Regarding these topics:<br>> > <br>> > ACPI tables for logging: The (U)EFI specification for TPM 2 don't
require <br>> > a TCPA table with the logging area because there seems to be
an API for <br>> > the OS for retrieving the log. UEFI seems to log into just some
buffer, <br>> > not connected to any ACPI table. For the BIOS we would still
need that <br>> > TCPA table. QEMU currently provides that. The Linux kernel (and
all other <br>> > OSes -- uuuh) would then have to allow a TCPA table for logging
for TPM 2 <br>> > even though we cannot point to a spec for that. Not sure whether
we can <br>> > create a standard for this little gap here...<br>> <br>> It sounds like the creators of the spec assumed only EFI machines<br>> would have a TPM2 device.  Unless there is evidence that OSes
will<br>> accept the ACPI/TCPA table in the new format, I'd be inclined to leave<br>> it in the old format.</font></tt><br><br><tt><font size=2>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.</font></tt><br><tt><font size=2><br>> <br>> > BIOS API: Some functions pass the entry to write into the log
via the <br>> > function directly. Patch 10 handles that and transforms that
entry into <br>> > the log entry format as required for TPM 1.2 or TPM 2 (log entries
are <br>> > differently formatted for TPM 1.2 and for TPM 2). So the only
remaining <br>> > problem I know of is the function that allows one to pass TPM
commands <br>> > through to the TPM. This may end up causing problems in the application
if <br>> > it was written for TPM 1.2 and now there's a TPM 2 running underneath,
<br>> > which doesn't understand the TPM 1.2 commands. I would say this
is likely <br>> > the smaller of the problems also considering that there are not
many <br>> > applications out there that use that API call. Possibility to
just shut <br>> > down that function call is certainly there.<br>> <br>> I'd say returning an error code for pass-through command requests
is<br>> the safest solution.</font></tt><br><br><tt><font size=2>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.</font></tt><br><br><tt><font size=2>   Stefan</font></tt><br><br><br><tt><font size=2><br>> <br>> -Kevin<br>> <br></font></tt><BR>