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: <20171023025723.zdmp5iwupssnqlzx@linux.intel.com>
Date:   Mon, 23 Oct 2017 05:57:23 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Alexander.Steffen@...ineon.com
Cc:     nayna@...ux.vnet.ibm.com, linux-integrity@...r.kernel.org,
        zohar@...ux.vnet.ibm.com, linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, peterhuewe@....de,
        tpmdd@...horst.net, jgunthorpe@...idianresearch.com,
        patrickc@...ibm.com
Subject: Re: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send()
 performance

On Fri, Oct 20, 2017 at 02:42:54PM +0000, Alexander.Steffen@...ineon.com wrote:
> > The TPM burstcount status indicates the number of bytes that can
> > be sent to the TPM without causing bus wait states.  Effectively,
> > it is the number of empty bytes in the command FIFO.
> > 
> > This patch optimizes the tpm_tis_send_data() function by checking
> > the burstcount only once. And if the burstcount is valid, it writes
> > all the bytes at once, permitting wait state.
> > 
> > After this change, performance on a TPM 1.2 with an 8 byte
> > burstcount for 1000 extends improved from ~41sec to ~14sec.
> > 
> > Suggested-by: Ken Goldman <kgold@...ux.vnet.ibm.com> in
> > conjunction with the TPM Device Driver work group.
> > Signed-off-by: Nayna Jain <nayna@...ux.vnet.ibm.com>
> > Acked-by: Mimi Zohar <zohar@...ux.vnet.ibm.com>
> > ---
> >  drivers/char/tpm/tpm_tis_core.c | 42 +++++++++++++++----------------------
> > ----
> >  1 file changed, 15 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/char/tpm/tpm_tis_core.c
> > b/drivers/char/tpm/tpm_tis_core.c
> > index b33126a35694..993328ae988c 100644
> > --- a/drivers/char/tpm/tpm_tis_core.c
> > +++ b/drivers/char/tpm/tpm_tis_core.c
> > @@ -316,7 +316,6 @@ static int tpm_tis_send_data(struct tpm_chip *chip,
> > u8 *buf, size_t len)
> >  {
> >  	struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev);
> >  	int rc, status, burstcnt;
> > -	size_t count = 0;
> >  	bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND;
> > 
> >  	status = tpm_tis_status(chip);
> > @@ -330,35 +329,24 @@ static int tpm_tis_send_data(struct tpm_chip *chip,
> > u8 *buf, size_t len)
> >  		}
> >  	}
> > 
> > -	while (count < len - 1) {
> > -		burstcnt = get_burstcount(chip);
> > -		if (burstcnt < 0) {
> > -			dev_err(&chip->dev, "Unable to read burstcount\n");
> > -			rc = burstcnt;
> > -			goto out_err;
> > -		}
> > -		burstcnt = min_t(int, burstcnt, len - count - 1);
> > -		rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv-
> > >locality),
> > -					 burstcnt, buf + count);
> > -		if (rc < 0)
> > -			goto out_err;
> > -
> > -		count += burstcnt;
> > -
> > -		if (wait_for_tpm_stat(chip, TPM_STS_VALID, chip-
> > >timeout_c,
> > -					&priv->int_queue, false) < 0) {
> > -			rc = -ETIME;
> > -			goto out_err;
> > -		}
> > -		status = tpm_tis_status(chip);
> > -		if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) {
> > -			rc = -EIO;
> > -			goto out_err;
> > -		}
> > +	/*
> > +	 * Get the initial burstcount to ensure TPM is ready to
> > +	 * accept data.
> > +	 */
> > +	burstcnt = get_burstcount(chip);
> > +	if (burstcnt < 0) {
> > +		dev_err(&chip->dev, "Unable to read burstcount\n");
> > +		rc = burstcnt;
> > +		goto out_err;
> >  	}
> > 
> > +	rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv->locality),
> > +			len - 1, buf);
> > +	if (rc < 0)
> > +		goto out_err;
> > +
> >  	/* write last byte */
> > -	rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality),
> > buf[count]);
> > +	rc = tpm_tis_write8(priv, TPM_DATA_FIFO(priv->locality), buf[len-
> > 1]);
> >  	if (rc < 0)
> >  		goto out_err;
> > 
> > --
> > 2.13.3
> 
> This seems to fail reliably with my SPI TPM 2.0. I get EIO when trying
> to send large amounts of data, e.g. with TPM2_Hash, and subsequent
> tests seem to take an unusual amount of time. More analysis probably
> has to wait until November, since I am going to be in Prague next
> week.
> 
> Alexander

For the time being I'll drop this patch from the next branch and keep it
in the master branch.

/Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ