linux-kernel - Re: [PATCH v2 3/6] tpm_tis

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]

Message-ID: <7daa4875-eddd-518d-2622-754ccfbfc421@infineon.com>
Date:   Wed, 17 Jul 2019 10:07:11 +0200
From:   Alexander Steffen <Alexander.Steffen@...ineon.com>
To:     Stephen Boyd <swboyd@...omium.org>,
        Peter Huewe <peterhuewe@....de>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
CC:     Andrey Pronin <apronin@...omium.org>,
        <linux-kernel@...r.kernel.org>, Jason Gunthorpe <jgg@...pe.ca>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        <linux-integrity@...r.kernel.org>,
        Duncan Laurie <dlaurie@...omium.org>,
        Guenter Roeck <groeck@...omium.org>,
        Dmitry Torokhov <dtor@...omium.org>
Subject: Re: [PATCH v2 3/6] tpm_tis_spi: add max xfer size

On 17.07.2019 00:45, Stephen Boyd wrote:
> From: Andrey Pronin <apronin@...omium.org>
> 
> Reject burstcounts larger than 64 bytes reported by tpm.

This is not the correct thing to do here. To quote the specification:

"burstCount is defined as the number of bytes that can be written to or 
read from the data FIFO by the software without incurring a wait state."
(https://trustedcomputinggroup.org/wp-content/uploads/TCG_PC_Client_Platform_TPM_Profile_PTP_2.0_r1.03_v22.pdf 
Page 84)

If the FIFO contains 1k of data, it is completely valid for the TPM to 
report that as its burstCount, there is no need to arbitrarily limit it.

Also, burstCount is a property of the high-level TIS protocol, that 
should not really care whether the low-level transfers are done via LPC 
or SPI (or I2C). Since tpm_tis_spi can only transfer 64 bytes at a time, 
it is its job to split larger transfers (which it does perfectly fine). 
This also has the advantage that burstCount needs only to be read once, 
and then we can do 16 SPI transfers in a row to read that 1k of data. 
With your change, it will read 64 bytes, then read burstCount again, 
before reading the next 64 bytes and so on. This unnecessarily limits 
performance.

Maybe you can describe the problem you're trying to solve in more 
detail, so that a better solution can be found, since this is clearly 
something not intended by the spec.

Alexander