linux-kernel - RE: [Patch V8 2/3] tpm_tis-spi: Add hardware wait polling

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>] [day] [month] [year] [list]

Date:   Thu, 23 Mar 2023 11:57:55 +0000
From:   Krishna Yarlagadda <kyarlagadda@...dia.com>
To:     Hillf Danton <hdanton@...a.com>
CC:     "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "peterhuewe@....de" <peterhuewe@....de>,
        "jgg@...pe.ca" <jgg@...pe.ca>,
        "jarkko@...nel.org" <jarkko@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [Patch V8 2/3] tpm_tis-spi: Add hardware wait polling

> -----Original Message-----
> From: Hillf Danton <hdanton@...a.com>
> Sent: 19 March 2023 19:58
> To: Krishna Yarlagadda <kyarlagadda@...dia.com>
> Cc: robh+dt@...nel.org; broonie@...nel.org; peterhuewe@....de;
> jgg@...pe.ca; jarkko@...nel.org; krzysztof.kozlowski+dt@...aro.org; linux-
> kernel@...r.kernel.org
> Subject: Re: [Patch V8 2/3] tpm_tis-spi: Add hardware wait polling
> 
> External email: Use caution opening links or attachments
> 
> 
> On 2 Mar 2023 09:48:03 +0530 Krishna Yarlagadda <kyarlagadda@...dia.com>
> > +static int tpm_tis_spi_hw_flow_transfer(struct tpm_tis_data *data,
> > +                                     u32 addr, u16 len, u8 *in,
> > +                                     const u8 *out)
> > +{
> > +     struct tpm_tis_spi_phy *phy = to_tpm_tis_spi_phy(data);
> > +     struct spi_transfer spi_xfer[3];
> > +     struct spi_message m;
> > +     u8 transfer_len;
> > +     int ret;
> > +
> > +     while (len) {
> > +             transfer_len = min_t(u16, len, MAX_SPI_FRAMESIZE);
> > +
> > +             spi_message_init(&m);
> > +             phy->iobuf[0] = (in ? 0x80 : 0) | (transfer_len - 1);
> > +             phy->iobuf[1] = 0xd4;
> > +             phy->iobuf[2] = addr >> 8;
> > +             phy->iobuf[3] = addr;
> > +
> > +             memset(&spi_xfer, 0, sizeof(spi_xfer));
> > +
> > +             spi_xfer[0].tx_buf = phy->iobuf;
> > +             spi_xfer[0].len = 1;
> > +             spi_message_add_tail(&spi_xfer[0], &m);
> > +
> > +             spi_xfer[1].tx_buf = phy->iobuf + 1;
> > +             spi_xfer[1].len = 3;
> > +             spi_message_add_tail(&spi_xfer[1], &m);
> > +
> > +             if (out) {
> > +                     spi_xfer[2].tx_buf = &phy->iobuf[4];
> > +                     spi_xfer[2].rx_buf = NULL;
> > +                     memcpy(&phy->iobuf[4], out, transfer_len);
> > +                     out += transfer_len;
> > +             }
> > +
> > +             if (in) {
> > +                     spi_xfer[2].tx_buf = NULL;
> > +                     spi_xfer[2].rx_buf = &phy->iobuf[4];
> > +             }
> > +
> > +             spi_xfer[2].len = transfer_len;
> > +             spi_message_add_tail(&spi_xfer[2], &m);
> > +
> > +             reinit_completion(&phy->ready);
> 
> What breaks without reinit? Or what sense made by init-ing it again?
When length is over frame size, this loop will run for more than
one iterations. Reinit to start transfer again.
KY
> > +
> > +             ret = spi_sync_locked(phy->spi_device, &m);
> > +             if (ret < 0)
> > +                     return ret;
> > +
> > +             if (in) {
> > +                     memcpy(in, &phy->iobuf[4], transfer_len);
> > +                     in += transfer_len;
> > +             }
> > +
> > +             len -= transfer_len;
> > +     }
> > +
> > +     return ret;
> > +}