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

[Tom Rini]

On Tue, Mar 20, 2018 at 03:51:22PM +0100, Miquel Raynal wrote:
> Hi Tom,
> 
> On Tue, 20 Mar 2018 10:04:55 -0400, Tom Rini <trini at konsulko.com> wrote:
> 
> > 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.
> 
> Actually the name is misleading as I don't want to "stringify".
> 
> I am looking for a way to easily fill a buffer of bytes from integer
> values, ie:
> 
> u32 value = 0x12345678;
> u8 buf[x] = { MACRO(value), ...} to be {0x12, 0x34, 0x56, 0x78, ...}
> 
> 
> >  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!
> 
> I see some TPM tests for v1.x, I can probably add some there. This will
> test the library functions but not the "user" commands.
> 
> To test the commands, I suggest following the lines I inserted in my
> cover letter, but maybe I can put it also in some documentation?
> 
> Would this fit your expectations?

We have a framework to run those commands on the target and confirm that
they behave as expected.  Please write the tests to run those commands
and confirm that they work as expected.  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/20180321/2c8f507a/attachment.sig>