subject:"Re\: \[U\-Boot\] \[PATCH 00\/18\] Introduce SPI TPM v2.0 support"

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

2018-03-29 Thread Simon Glass

Hi Miquel,

On 29 March 2018 at 15:39, Miquel Raynal  wrote:
> Hi Simon and Tom,
>
> On Fri, 23 Mar 2018 08:42:02 -0600, Simon Glass 
> wrote:
>
>> Hi Miquel,
>>
>> On 21 March 2018 at 07:49, Tom Rini  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  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  
>> >> > > 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  
>> >> > > > > 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

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

2018-03-29 Thread Miquel Raynal

Hi Simon and Tom,

On Fri, 23 Mar 2018 08:42:02 -0600, Simon Glass 
wrote:

> Hi Miquel,
> 
> On 21 March 2018 at 07:49, Tom Rini  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  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  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  
> >> > > > > 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

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

2018-03-23 Thread Simon Glass

Hi Miquel,

On 21 March 2018 at 07:49, Tom Rini  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  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  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  
>> > > > > 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-03-21 Thread 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  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  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  
> > > > > 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


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-03-20 Thread Miquel Raynal

Hi Tom,

On Tue, 20 Mar 2018 10:04:55 -0400, Tom Rini  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  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  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


-- 
Miquel Raynal, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-03-20 Thread 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  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  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


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-03-20 Thread Miquel Raynal

Hi Tom,

Sorry for the delay.

On Fri, 9 Mar 2018 07:18:40 -0500, Tom Rini  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  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 

-- 
Miquel Raynal, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-03-09 Thread Tom Rini

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  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?

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-03-08 Thread Miquel Raynal

Hi Tom,

On Thu, 8 Mar 2018 12:20:30 -0500, Tom Rini  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

-- 
Miquel Raynal, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2018-03-08 Thread Tom Rini

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?

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

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

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

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

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

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

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

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

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

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

10 matches

Site Navigation

Mail list logo

Footer information