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

[Simon Glass]

Hi Miquel,

On 21 March 2018 at 07:49, Tom Rini <trini at konsulko.com> wrote:
> 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!

Re sandbox, it has a TPM emulator used for testing in
tpm_tis_sandbox.c - you should be able to add something similar for
v2.

Regards,
Simon