linux-kernel - Re: [PATCH] tpm_tis_spi: Don't send anything during flow control

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 4 Jun 2020 06:48:58 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:     Peter Huewe <peterhuewe@....de>,
        Andrey Pronin <apronin@...omium.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jason Gunthorpe <jgg@...pe.ca>,
        linux-integrity@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tpm_tis_spi: Don't send anything during flow control

Hi,

On Thu, Jun 4, 2020 at 2:40 AM Jarkko Sakkinen
<jarkko.sakkinen@...ux.intel.com> wrote:
>
> On Mon, Jun 01, 2020 at 03:54:03PM -0700, Doug Anderson wrote:
> > Does that answer your question, or were you worried about us needing
> > to init iobuf[0] to 0 in some other case?
> >
> > -Doug
>
> No, but it should be treated as a bug fix for CR50 implementation i.e.
> for 797c0113c9a481d4554988d70b5b52fae657262f, or is there some reason
> why it shouldn't?

As talked about in the commit message, I think this is a slight
cleanup for non-Cr50 too.  Specifically if we end up running through
the TPM_RETRY loop a second time we weren't re-initting "phy->iobuf[0]
= 0;"  That means that the 2nd time through the loop we were actually
sending the TPM back the byte that the TPM sent us the first time
through the loop.

Presumably this doesn't matter much, but it still feels nicer not to
be sending the TPM's bytes back to it when we're not really supposed
to.

Also, as mentioned in the commit message, I haven't observed this
fixing any problems.  I only came up with it from code inspection
while trying to track something else down.

-Doug