[U-Boot] [PATCH 00/18] Introduce SPI TPM v2.0 support

[Tom Rini]

On Tue, Mar 20, 2018 at 02:36:56PM +0100, Miquel Raynal wrote:
> Hi Tom,
> 
> Sorry for the delay.
> 
> On Fri, 9 Mar 2018 07:18:40 -0500, Tom Rini <trini at konsulko.com> wrote:
> 
> > On Fri, Mar 09, 2018 at 08:53:40AM +0100, Miquel Raynal wrote:
> > > Hi Tom,
> > > 
> > > On Thu, 8 Mar 2018 12:20:30 -0500, Tom Rini <trini at konsulko.com> wrote:
> > >   
> > > > On Thu, Mar 08, 2018 at 04:40:03PM +0100, Miquel Raynal wrote:
> > > >   
> > > > > Current U-Boot supports TPM v1.2 specification. The new specification
> > > > > (v2.0) is not backward compatible and renames/introduces several
> > > > > functions.
> > > > > 
> > > > > This series introduces a new SPI driver following the TPM v2.0
> > > > > specification. It has been tested on a ST TPM but should be usable with
> > > > > others v2.0 compliant chips.
> > > > > 
> > > > > Then, basic functionalities are introduced one by one for the v2.0
> > > > > specification. The INIT command now can receive a parameter to
> > > > > distinguish further TPMv1/TPMv2 commands. After that, the library itself
> > > > > will know which one is pertinent and will return a special error if the
> > > > > desired command is not supported for the selected specification.    
> > > > 
> > > > Thanks for doing all of this.  Can you please enable this feature on
> > > > sandbox and/or an x86 QEMU variant where I assume we could also then
> > > > setup automated testing?
> > > >   
> > > 
> > > Not sure I understand your request correctly: the TPM commands are
> > > already available in the sandbox (I don't see what I could add), I just
> > > extended the current set of commands.
> > > 
> > > However, even with these commands, we won't be able to test them in a
> > > sandbox unless with an actual device.
> > > 
> > > I probably miss something, can you explain a bit more what you would
> > > like?  
> > 
> > Can we add a valid TPM via QEMU and then test it that way?  If so, we
> > should enable the TPM code on qemu-x86_64 (and, well, if we can pass it
> > on other arches, other QEMU targets) and write some test/py/tests/ code
> > that exercises the TPM commands.  Does that make sense?
> > 
> 
> I suppose this is doable, but for what I know, the effort is
> consequent. TPM 2.0 are not compatible at all with TPM 1.x , the
> packets exchanged at TPM level are completely different. Hence, I
> think there is almost nothing that we can take from the TPM 1.x
> implementation already existing in QEMU.

Ah, OK.  I thought QEMU had a TPM 2.0 implementation now too, but I see
I'm mistaken.

> I am certain we all would benefit such a contribution, however I'm
> not sure I could handle that anytime soon.
> 
> About the series, I think it would be better that I change a macro name
> ("STRINGIFY", which is wrongly named), I will send a v2 soon, can you
> tell me its status otherwise?

We have the usual linux/stringify.h header available, so yes, you should
make use of that.  And I still would like to see tests written, even if
they can only be executed on $board with $TPM attached via $interface,
with those 3 variables documented so that others can try it out too.
Does that make sense?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180320/0bbb50f6/attachment.sig>