Hello Kevin,

 

Understood.

 

Thanks.

 

 

Best Regards,

Wim Vervoorn

 

Eltan B.V.

Ambachtstraat 23

5481 SM Schijndel

The Netherlands

 

T : +31-(0)73-594 46 64

E : wvervoorn@eltan.com

W : http://www.eltan.com

"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES." 

 

 

 

 

From: Stefan Berger [mailto:stefanb@us.ibm.com]
Sent: Tuesday, December 22, 2015 3:30 PM
To: Wim Vervoorn <wvervoorn@eltan.com>
Cc: Kevin O'Connor <kevin@koconnor.net>; seabios@seabios.org
Subject: RE: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33

 

Wim Vervoorn <wvervoorn@eltan.com> wrote on 12/22/2015 09:15:55 AM:

>
> Hello Stefan,

>  
> I think it will work perfectly for the higher level functions like :
> tpm_smbios_measure(void) etc. Here you can easily implement tpm 1.2
> and 2.0 handling. For the functions like tpm_add_measurement_to_log()
> I don’t think it is that easy or useful. For those it’s probably
> better to have a tpm 1.2 and a tpm 2.0 variant each with their own
> API but not with a wrapper.


If TPM 2 is not operated in sha1 mode, then we may need different *internal* functions, yes (tpm2_bar()).
Otherwise it's mostly byte streams being passed into the TPM parts to which sha1 is applied if needed; the
exception is the BIOS API which seems to return SHA1 hashes in some structures.

For the BIOS API functions where applications expect structures with embedded sha1 hashes, we will
need to restrict those APIs to sha1 mode, return failure otherwise. If the standard defines structures (for BIOS)
for sha256 etc.,  and possibly new API functions, then we can implement those for TPM 2 and they would result
in an error if invoked by TPM 1.2 (which only supports sha1).


   Stefan

>  
> Please note I did not look into all details so I might be seeing
> problems that aren’t there (or can be solved easily).

>  
>  
> Best Regards,
> Wim Vervoorn
>  
> Eltan B.V.
> Ambachtstraat 23
> 5481 SM Schijndel
> The Netherlands
>  
> T : +31-(0)73-594 46 64
> E : wvervoorn@eltan.com
> W : http://www.eltan.com
> "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE
> INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS
> STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR,
> PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664
> OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."

>  
>  
>  
>  
>  
>  
> From: Stefan Berger [mailto:stefanb@us.ibm.com]
> Sent: Tuesday, December 22, 2015 2:56 PM
> To: Wim Vervoorn <wvervoorn@eltan.com>
> Cc: Kevin O'Connor <kevin@koconnor.net>; seabios@seabios.org
> Subject: RE: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33

>  
> Wim Vervoorn <wvervoorn@eltan.com> wrote on 12/22/2015 08:43:54 AM:
>
> >
> > Hello Stefan,
> >  
> > I have my doubts. This will work fine as long as the toplevel
> > function tpm_foo() in your example can be implemented to have a
> > single API independent of the required support. If the API differs
> > between the tpm 1.2 and tpm 2.0 case I think it will only be
> confusing things.
> >  
> > Given the differences between tpm 1.2 and 2.0 do you think you will
> > be able to maintain this single API?
>
> The top level function tpm_foo() will be called by other SeaBIOS
> code for doing TPM initialization,
> measurements, the menu, S3 resume, and for the BIOS API. For the API
> we would support the same API
> for TPM 1.2 and for TPM 2. The difference between the tpm12_foo and
> tpm2_foo functions are mainly
> that different TPM commands are created and sent to the TIS. So far,
> this works fine.
>
> Do you have concrete concerns regarding this? How else would you do it ?
>
> Regards,
>    Stefan
>
> >  
> >  
> > Best Regards,
> > Wim Vervoorn
> >  
> > Eltan B.V.
> > Ambachtstraat 23
> > 5481 SM Schijndel
> > The Netherlands
> >  
> > T : +31-(0)73-594 46 64
> > E : wvervoorn@eltan.com
> > W :
http://www.eltan.com
> > "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE
> > INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS
> > STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR,
> > PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664
> > OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
> >  
> >  
> >  
> >  
> > From: Stefan Berger [
mailto:stefanb@us.ibm.com]
> > Sent: Monday, December 21, 2015 5:50 PM
> > To: Kevin O'Connor <kevin@koconnor.net>
> > Cc: seabios@seabios.org; Wim Vervoorn <wvervoorn@eltan.com>
> > Subject: Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33
> >  
> > "Kevin O'Connor" <kevin@koconnor.net> wrote on 12/17/2015 05:22:56 PM:
> >
> > >
> > > On Mon, Nov 30, 2015 at 11:32:05AM +0000, Wim Vervoorn wrote:
> > > > Hello,
> > > >
> > > > I noticed that a lot of work is going on for the TPM support in SeaBIOS.
> > > >
> > > > All of this work is TPM 1.2 based. I was wondering if there are any
> > > > plans to support TPM 2.0 in the future.
> > >
> > > I'm not aware of any plans.
> >
> > We're working on it...
> >
> >
> > So maybe you have some comments to the following:
> >
> > There will be a patch for probing the TPM TIS hardware interface for
> > whether there's a TPM 1.2 or a TPM 2.
> > We then have a patch for prefixing all TPM 1.2 functions with tpm12_
> > and then introduce functions like these ones here:
> >
> > static ... tpm12_foo() { ... }
> > static ... tpm2_foo() { ... }
> >
> > tpm_foo()
> > {
> >     [...]
> >
> >     switch (tpmversion) {
> >     case TPM_VERSION_1_2:
> >         tpm12_foo()
> >         break;
> >     case TPM_VERSION_2:
> >         tpm2_foo();
> >         break;
> >     }
> >
> >     [...]
> > }
> >
> > That way the probing will lead us to use either TPM1.2 or TPM 2
> > specific code. There will be multiple such constructs in tcgbios.c file.
> >
> >    Stefan