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?
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.
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.
-Kevin
"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-%28ener... 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
-
Kevin O'Connor -
Stefan Berger