linux-kernel - Re: [PATCH 5/5] tpm_tis_spi: Add small delay after last transfer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 17 Feb 2017 08:26:55 +0100
From:   Peter Huewe <peterhuewe@....de>
To:     Christophe Ricard <christophe.ricard@...il.com>,
        Peter Huewe <peter.huewe@...ineon.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
CC:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
        tpmdd-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
        Christophe Ricard <christophe-h.ricard@...com>,
        stable@...r.kernel.org,
        Alexander Steffen <Alexander.Steffen@...ineon.com>
Subject: Re: [PATCH 5/5] tpm_tis_spi: Add small delay after last transfer



Am 17. Februar 2017 06:09:42 MEZ schrieb Christophe Ricard <christophe.ricard@...il.com>:
>Are you sure it is not better to introduce this delay directly in the 
>rpi spi driver ?
>
>Other than that i don't see any issue with it.

Yes - it would be perfect to fix the issue in the upstream rpi spi master driver.
However this only happens sporadically in some strange cases (i.e. 300-500khz, single byte transfer after having more bytes in the same #cs frame) (unrelated to the tpm)

We are still looking into it, why /where it happens and how to reproduce it reliably and then file a bug/fix it.

For now however the priority is to make the tpm_tis_spi driver work reliably also on the rpi, and this is what this workaround does.

We can simply remove it once the rpi spi master is fixed.

Peter
>
>
>On 16/02/2017 08:09, Peter Huewe wrote:
>> Testing the implementation with a Raspberry Pi 2 showed that under
>some
>> circumstances its SPI master erroneously releases the CS line before
>the
>> transfer is complete, i.e. before the end of the last clock. In this
>case
>> the TPM ignores the transfer and misses for example the GO command.
>The
>> driver is unable to detect this communication problem and will wait
>for a
>> command response that is never going to arrive, timing out
>eventually.
>>
>> As a workaround, the small delay ensures that the CS line is held
>long
>> enough, even with a faulty SPI master. Other SPI masters are not
>affected,
>> except for a negligible performance penalty.
>>
>> Cc: <stable@...r.kernel.org>
>> Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy")
>> Signed-off-by: Alexander Steffen <Alexander.Steffen@...ineon.com>
>> Signed-off-by: Peter Huewe <peter.huewe@...ineon.com>
>> ---
>>   drivers/char/tpm/tpm_tis_spi.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/char/tpm/tpm_tis_spi.c
>b/drivers/char/tpm/tpm_tis_spi.c
>> index b50c5b072df3..685c51bf5d7e 100644
>> --- a/drivers/char/tpm/tpm_tis_spi.c
>> +++ b/drivers/char/tpm/tpm_tis_spi.c
>> @@ -110,6 +110,7 @@ static int tpm_tis_spi_transfer(struct
>tpm_tis_data *data, u32 addr, u8 len,
>>   
>>   		spi_xfer.cs_change = 0;
>>   		spi_xfer.len = transfer_len;
>> +		spi_xfer.delay_usecs = 5;
>>   
>>   		if (direction) {
>>   			spi_xfer.tx_buf = NULL;

-- 
Sent from my mobile