Hi Miquel, On 29 March 2018 at 15:39, Miquel Raynal <[email protected]> wrote: > Hi Simon and Tom, > > On Fri, 23 Mar 2018 08:42:02 -0600, Simon Glass <[email protected]> > wrote: > >> Hi Miquel, >> >> On 21 March 2018 at 07:49, Tom Rini <[email protected]> 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 <[email protected]> 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 <[email protected]> >> >> > > 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 <[email protected]> >> >> > > > > 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. > > I wrote a complete test suite for all the TPMv2.0 commands. It runs > completely fine with real hardware, see the last patch of the v2 series. > I had a look to sandbox but I'm sorry, I really don't have enough time > for now to achieve this additional work, I really hope the full Python > test suite will be enough.
This should not take very long to do. I am not keen to add this new support without sandbox tests. The Python test suite is a great idea, but running it on real hardware is not an option for most people. Lots of people have made big efforts to improve the sandbox testing in U-Boot. We need to keep pushing it forward, not regressing. Regards, Simon _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
