<tt><font size=2>Wim Vervoorn <wvervoorn@eltan.com> wrote on 12/22/2015
09:15:55 AM:<br><br>> <br>> Hello Stefan,</font></tt><br><tt><font size=2>> </font></tt><br><tt><font size=2>> I think it will work perfectly for the higher
level functions like : <br>> tpm_smbios_measure(void) etc. Here you can easily implement tpm 1.2
<br>> and 2.0 handling. For the functions like tpm_add_measurement_to_log()
<br>> I don’t think it is that easy or useful. For those it’s probably
<br>> better to have a tpm 1.2 and a tpm 2.0 variant each with their own
<br>> API but not with a wrapper.</font></tt><br><br><tt><font size=2>If TPM 2 is not operated in sha1 mode, then we may
need different *internal* functions, yes (tpm2_bar()).</font></tt><br><tt><font size=2>Otherwise it's mostly byte streams being passed into
the TPM parts to which sha1 is applied if needed; the</font></tt><br><tt><font size=2>exception is the BIOS API which seems to return SHA1
hashes in some structures.</font></tt><br><br><tt><font size=2>For the BIOS API functions where applications expect
structures with embedded sha1 hashes, we will</font></tt><br><tt><font size=2>need to restrict those APIs to sha1 mode, return failure
otherwise. If the standard defines structures (for BIOS)</font></tt><br><tt><font size=2>for sha256 etc., and possibly new API functions,
then we can implement those for TPM 2 and they would result</font></tt><br><tt><font size=2>in an error if invoked by TPM 1.2 (which only supports
sha1).</font></tt><br><br><br><tt><font size=2> Stefan</font></tt><br><br><tt><font size=2>> </font></tt><br><tt><font size=2>> Please note I did not look into all details so
I might be seeing <br>> problems that aren’t there (or can be solved easily).</font></tt><br><tt><font size=2>> </font></tt><br><tt><font size=2>> </font></tt><br><tt><font size=2>> Best Regards,</font></tt><br><tt><font size=2>> Wim Vervoorn</font></tt><br><tt><font size=2>> </font></tt><br><tt><font size=2>> Eltan B.V.</font></tt><br><tt><font size=2>> Ambachtstraat 23</font></tt><br><tt><font size=2>> 5481 SM Schijndel</font></tt><br><tt><font size=2>> The Netherlands</font></tt><br><tt><font size=2>> </font></tt><br><tt><font size=2>> T : +31-(0)73-594 46 64</font></tt><br><tt><font size=2>> E : wvervoorn@eltan.com</font></tt><br><tt><font size=2>> W : </font></tt><a href=http://www.eltan.com/><tt><font size=2>http://www.eltan.com</font></tt></a><br><tt><font size=2>> "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION.
UNLESS YOU ARE THE <br>> INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS <br>> STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, <br>> PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664
<br>> OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
</font></tt><br><tt><font size=2>> </font></tt><br><tt><font size=2>> </font></tt><br><tt><font size=2>> </font></tt><br><tt><font size=2>> </font></tt><br><tt><font size=2>> </font></tt><br><tt><font size=2>> </font></tt><br><tt><font size=2>> From: Stefan Berger [</font></tt><a href=mailto:stefanb@us.ibm.com><tt><font size=2>mailto:stefanb@us.ibm.com</font></tt></a><tt><font size=2>]
<br>> Sent: Tuesday, December 22, 2015 2:56 PM<br>> To: Wim Vervoorn <wvervoorn@eltan.com><br>> Cc: Kevin O'Connor <kevin@koconnor.net>; seabios@seabios.org<br>> Subject: RE: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33</font></tt><br><tt><font size=2>> </font></tt><br><tt><font size=2>> Wim Vervoorn <wvervoorn@eltan.com> wrote
on 12/22/2015 08:43:54 AM:<br>> <br>> > <br>> > Hello Stefan,<br>> > <br>> > I have my doubts. This will work fine as long as the toplevel
<br>> > function tpm_foo() in your example can be implemented to have
a <br>> > single API independent of the required support. If the API differs
<br>> > between the tpm 1.2 and tpm 2.0 case I think it will only be
<br>> confusing things.<br>> > <br>> > Given the differences between tpm 1.2 and 2.0 do you think you
will <br>> > be able to maintain this single API?<br>> <br>> The top level function tpm_foo() will be called by other SeaBIOS <br>> code for doing TPM initialization, <br>> measurements, the menu, S3 resume, and for the BIOS API. For the API<br>> we would support the same API<br>> for TPM 1.2 and for TPM 2. The difference between the tpm12_foo and
<br>> tpm2_foo functions are mainly<br>> that different TPM commands are created and sent to the TIS. So far,<br>> this works fine.<br>> <br>> Do you have concrete concerns regarding this? How else would you do
it ?<br>> <br>> Regards,<br>> Stefan<br>> <br>> > <br>> > <br>> > Best Regards,<br>> > Wim Vervoorn<br>> > <br>> > Eltan B.V.<br>> > Ambachtstraat 23<br>> > 5481 SM Schijndel<br>> > The Netherlands<br>> > <br>> > T : +31-(0)73-594 46 64<br>> > E : wvervoorn@eltan.com<br>> > W : </font></tt><a href=http://www.eltan.com/><tt><font size=2>http://www.eltan.com</font></tt></a><tt><font size=2><br>> > "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS
YOU ARE THE <br>> > INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS
<br>> > STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR,
<br>> > PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664
<br>> > OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
<br>> > <br>> > <br>> > <br>> > <br>> > From: Stefan Berger [</font></tt><a href=mailto:stefanb@us.ibm.com><tt><font size=2>mailto:stefanb@us.ibm.com</font></tt></a><tt><font size=2>]
<br>> > Sent: Monday, December 21, 2015 5:50 PM<br>> > To: Kevin O'Connor <kevin@koconnor.net><br>> > Cc: seabios@seabios.org; Wim Vervoorn <wvervoorn@eltan.com><br>> > Subject: Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33<br>> > <br>> > "Kevin O'Connor" <kevin@koconnor.net> wrote on
12/17/2015 05:22:56 PM:<br>> > <br>> > > <br>> > > On Mon, Nov 30, 2015 at 11:32:05AM +0000, Wim Vervoorn wrote:<br>> > > > Hello,<br>> > > > <br>> > > > I noticed that a lot of work is going on for the TPM
support in SeaBIOS.<br>> > > > <br>> > > > All of this work is TPM 1.2 based. I was wondering
if there are any<br>> > > > plans to support TPM 2.0 in the future.<br>> > > <br>> > > I'm not aware of any plans.<br>> > <br>> > We're working on it...<br>> > <br>> > <br>> > So maybe you have some comments to the following:<br>> > <br>> > There will be a patch for probing the TPM TIS hardware interface
for<br>> > whether there's a TPM 1.2 or a TPM 2.<br>> > We then have a patch for prefixing all TPM 1.2 functions with
tpm12_<br>> > and then introduce functions like these ones here:<br>> > <br>> > static ... tpm12_foo() { ... }<br>> > static ... tpm2_foo() { ... }<br>> > <br>> > tpm_foo()<br>> > {<br>> > [...]<br>> > <br>> > switch (tpmversion) {<br>> > case TPM_VERSION_1_2:<br>> > tpm12_foo()<br>> > break;<br>> > case TPM_VERSION_2:<br>> > tpm2_foo();<br>> > break;<br>> > }<br>> > <br>> > [...]<br>> > }<br>> > <br>> > That way the probing will lead us to use either TPM1.2 or TPM
2 <br>> > specific code. There will be multiple such constructs in tcgbios.c
file.<br>> > <br>> > Stefan</font></tt><BR>