| Message ID | 20180308154021.25255-1-miquel.raynal@bootlin.com |
|---|---|
| Headers | show |
| Series | Introduce SPI TPM v2.0 support | expand |
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?
Hi Tom, On Thu, 8 Mar 2018 12:20:30 -0500, Tom Rini <trini@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? Thank you, Miquèl
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@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?
Hi Tom, Sorry for the delay. On Fri, 9 Mar 2018 07:18:40 -0500, Tom Rini <trini@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@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. 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? Thank you, Miquèl
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@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@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!
Hi Tom, On Tue, 20 Mar 2018 10:04:55 -0400, Tom Rini <trini@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@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@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? [1] https://lists.denx.de/pipermail/u-boot/2018-March/322286.html Thanks, Miquèl
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@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@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@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!
Hi Miquel, On 21 March 2018 at 07:49, Tom Rini <trini@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@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@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@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
Hi Simon and Tom, On Fri, 23 Mar 2018 08:42:02 -0600, Simon Glass <sjg@chromium.org> wrote: > Hi Miquel, > > On 21 March 2018 at 07:49, Tom Rini <trini@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@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@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@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. 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. Regards, Miquèl
Hi Miquel, On 29 March 2018 at 15:39, Miquel Raynal <miquel.raynal@bootlin.com> wrote: > Hi Simon and Tom, > > On Fri, 23 Mar 2018 08:42:02 -0600, Simon Glass <sjg@chromium.org> > wrote: > >> Hi Miquel, >> >> On 21 March 2018 at 07:49, Tom Rini <trini@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@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@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@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. > > 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