[SeaBIOS] [RFC PATCH v1 0/9] Add TPM 2 support
stefanb at us.ibm.com
Tue Feb 2 15:36:51 CET 2016
"Kevin O'Connor" <kevin at 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 at 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
> > 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,
> > > is there hardware available on coreboot with the tpm2 hardware?
> > I did all the testing of these patches with the vTPM with CUSE
> > integrated into QEMU. Unfortunately the vTPM-QEMU integration train
> > a wreck now following comments on QEMU mailing list. So, I don't know
> > 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.
Devices with TPM 2 are also shipping:
> > You know the TPM 1.2 PC BIOS specification, right? I think we can say
> > many of the functions implemented in this series for TPM 2 are
> > because of how it's done for TPM 1.2 as well as properties of the TPM
> > 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
> > leeway we have to go about this in the areas of ACPI tables for
> > and the API. Regarding these topics:
> > ACPI tables for logging: The (U)EFI specification for TPM 2 don't
> > a TCPA table with the logging area because there seems to be an API
> > the OS for retrieving the log. UEFI seems to log into just some
> > 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
> > OSes -- uuuh) would then have to allow a TCPA table for logging for
> > even though we cannot point to a spec for that. Not sure whether we
> > 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
> > 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
> > 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
> > 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
> > the smaller of the problems also considering that there are not many
> > applications out there that use that API call. Possibility to just
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SeaBIOS