Atmel I2C TPM transfer length issues

Atmel I2C TPM transfer length issues

[Andrew Lunn]

Hi Jason

I'm hoping you can help me with an issue i have with an ATMEL I2C
TPM. I have one connected to an DLN2 USB-I2C bus controller. Initial
probe works, i can get the capabilites in /sys/class/tpm/tpm0,
tpm_version etc:

/sys/class/tpm/tpm0# cat caps 
Manufacturer: 0x41544d4c
TCG version: 1.2
Firmware version: 66.4

But i have issues with pubek and other long i2c transfers:

/sys/class/tpm/tpm0# hexdump pubek
[11621.731960] i2c i2c-11: adapter quirk: msg too long (addr 0x0029, size 314, read)
[11621.738208] tpm tpm0: tpm_transmit: tpm_recv: error -95

The dln2 i2c bus controller has a transfer limit of 256 bytes. Getting
the pubek is doing a read for 314 bytes, which is getting rejected.

Is there any way to fragment the reads/writes? Looking at
tpm_i2c_atmel i don't see any. It seems the raw TCG commands need to
be passed in a single i2c transaction. The comment in i2c_atmel_recv()
suggests that multiple reads will always start from the beginning of
the TCG response. There are no comments in the send function, but i
guess an I2C start condition indicates the start of a new command?

Or am i missing something?

Can fragmentation happen at a higher layer?

Any other ideas?

Thanks
	Andrew

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Atmel I2C TPM transfer length issues

[Peter Huewe]

Am 14. Februar 2017 03:33:36 MEZ schrieb Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>:
>Hi Jason
>
>I'm hoping you can help me with an issue i have with an ATMEL I2C
>TPM. I have one connected to an DLN2 USB-I2C bus controller. Initial
>probe works, i can get the capabilites in /sys/class/tpm/tpm0,
>tpm_version etc:
>
>/sys/class/tpm/tpm0# cat caps 
>Manufacturer: 0x41544d4c
>TCG version: 1.2
>Firmware version: 66.4
>
>But i have issues with pubek and other long i2c transfers:
>
>/sys/class/tpm/tpm0# hexdump pubek
>[11621.731960] i2c i2c-11: adapter quirk: msg too long (addr 0x0029,
>size 314, read)
>[11621.738208] tpm tpm0: tpm_transmit: tpm_recv: error -95
>
>The dln2 i2c bus controller has a transfer limit of 256 bytes. Getting
>the pubek is doing a read for 314 bytes, which is getting rejected.
>
>Is there any way to fragment the reads/writes? Looking at
>tpm_i2c_atmel i don't see any. It seems the raw TCG commands need to
>be passed in a single i2c transaction. The comment in i2c_atmel_recv()
>suggests that multiple reads will always start from the beginning of
>the TCG response. There are no comments in the send function, but i
>guess an I2C start condition indicates the start of a new command?
>
>Or am i missing something?
>
>Can fragmentation happen at a higher layer?
>
>Any other ideas?

Just limit the value which get_burstcount() returns to 256.
This should do the trick - because that would be the mechanism the tpm itself would use to fragment its response.
Atleast for other tpms like our infineon slb9645 i2c tpm that would work.


>
>Thanks
>	Andrew
>
>------------------------------------------------------------------------------
>Check out the vibrant tech community on one of the world's most
>engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>_______________________________________________
>tpmdd-devel mailing list
>tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

-- 
Sent from my mobile

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Atmel I2C TPM transfer length issues

[Andrew Lunn]

> Just limit the value which get_burstcount() returns to 256.
>
> This should do the trick - because that would be the mechanism the
> tpm itself would use to fragment its response.  Atleast for other
> tpms like our infineon slb9645 i2c tpm that would work.

Yes, that was one idea i had. But then i found the comment on the top
of tpm_i2c_atmel:

 * Teddy Reed determined the basic I2C command flow, unlike other I2C TPM
 * devices the raw TCG formatted TPM command data is written via I2C and then
 * raw TCG formatted TPM command data is returned via I2C.

The driver does not do anything like read the burst size and then
transfer in blocks. It reads/writes all in one go.

However, you have answered what was going to be a follow question. The
hardware is not yet set in stone. We could change the TPM. Use the
Infinion TPM with a modified get_burstcount(). And you think this will
work. Great.

Thanks
	Andrew

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Atmel I2C TPM transfer length issues

[Peter Huewe]

Am 14. Februar 2017 14:05:11 MEZ schrieb Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>:
>> Just limit the value which get_burstcount() returns to 256.
>>
>> This should do the trick - because that would be the mechanism the
>> tpm itself would use to fragment its response.  Atleast for other
>> tpms like our infineon slb9645 i2c tpm that would work.
>
>Yes, that was one idea i had. But then i found the comment on the top
>of tpm_i2c_atmel:
>
>* Teddy Reed determined the basic I2C command flow, unlike other I2C
>TPM
>* devices the raw TCG formatted TPM command data is written via I2C and
>then
> * raw TCG formatted TPM command data is returned via I2C.
>
>The driver does not do anything like read the burst size and then
>transfer in blocks. It reads/writes all in one go.

Sorry I should have read the code before replying. I just remembered that one case we solved a similar issue on a qualcomm master with the same limitation - and limiting the burstcount worked fine for us.

>From the code and comments it seems that the tpm does not offer any continuation or offset mechanism.

>
>However, you have answered what was going to be a follow question. The
>hardware is not yet set in stone. We could change the TPM. Use the
>Infinion TPM with a modified get_burstcount(). And you think this will
>work. Great.

As a heads up in my dayjob I do work for Infineon.
I did not intend to advertise our tpm, but we have resolved a similar situation.

Thanks,
Peter


>
>Thanks
>	Andrew

-- 
Sent from my mobile

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Atmel I2C TPM transfer length issues

[Jason Gunthorpe]

On Tue, Feb 14, 2017 at 02:05:11PM +0100, Andrew Lunn wrote:
> > Just limit the value which get_burstcount() returns to 256.
> >
> > This should do the trick - because that would be the mechanism the
> > tpm itself would use to fragment its response.  Atleast for other
> > tpms like our infineon slb9645 i2c tpm that would work.
> 
> Yes, that was one idea i had. But then i found the comment on the top
> of tpm_i2c_atmel:
> 
>  * Teddy Reed determined the basic I2C command flow, unlike other I2C TPM
>  * devices the raw TCG formatted TPM command data is written via I2C and then
>  * raw TCG formatted TPM command data is returned via I2C.
> 
> The driver does not do anything like read the burst size and then
> transfer in blocks. It reads/writes all in one go.

Yes, as far as I know, there is no option to do a smaller I2C read,
the I2C controller must support large reads. Future reads return the
first bytes of the message and I know of no way to offset the read.

> However, you have answered what was going to be a follow question. The
> hardware is not yet set in stone. We could change the TPM. Use the
> Infinion TPM with a modified get_burstcount(). And you think this will
> work. Great.

FWIW, on all our hardware we design for 2-3 different TPMs because
they are a bit difficult to get. There is now a new TCG specification
for I2C and SPI connected TPMs, so there may be better choices for
compatability.

IIRC, our alt for the atmel i2c part is a nuvoton part.

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot