[SeaBIOS] [RFC PATCH v1 0/9] Add TPM 2 support

[Stefan Berger]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.seabios.org/pipermail/seabios/attachments/20160202/1bfbe5d5/attachment.html>