All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrey Pronin <apronin@chromium.org>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Peter Huewe <peterhuewe@gmx.de>,
	Marcel Selhorst <tpmdd@selhorst.net>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
	Christophe Ricard <christophe.ricard@gmail.com>,
	Andrey Pronin <apronin@chromium.org>
Subject: [PATCH v2 1/2] tpm_tis_core: add optional max xfer size check
Date: Tue, 19 Jul 2016 19:34:19 -0700	[thread overview]
Message-ID: <faf81974821d1748f671888afffba5721847aa6d.1468981325.git.apronin@chromium.org> (raw)
In-Reply-To: <cover.1468981325.git.apronin@chromium.org>
In-Reply-To: <cover.1468981325.git.apronin@chromium.org>

If tpm reports a bigger burstcnt than allowed by the physical protocol,
re-query the burstcnt and correct, if needed, if still too large.

In practice, seen in case of xfer issues (e.g. in spi interface case,
lost header causing flow control issues and wrong values returned on read
from TPM_STS). Without catching, causes the physical layer to reject xfer,
while is easily preventable by re-querying TPM_STS.

Signed-off-by: Andrey Pronin <apronin@chromium.org>
---
 drivers/char/tpm/tpm_tis_core.c | 18 ++++++++++++++++--
 drivers/char/tpm/tpm_tis_core.h |  1 +
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index d66f51b..ffc1acb 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -158,6 +158,7 @@ static int get_burstcount(struct tpm_chip *chip)
 	unsigned long stop;
 	int burstcnt, rc;
 	u32 value;
+	bool retry_burstcnt = false;
 
 	/* wait for burstcount */
 	/* which timeout value, spec has 2 answers (c & d) */
@@ -168,8 +169,21 @@ static int get_burstcount(struct tpm_chip *chip)
 			return rc;
 
 		burstcnt = (value >> 8) & 0xFFFF;
-		if (burstcnt)
-			return burstcnt;
+		if (burstcnt) {
+			/* If burstcnt is larger than max allowed xfer
+			 * size, retry once - may be a glitch. Return
+			 * max_xfer_size on the 2nd try to avoid being
+			 * stuck forever.
+			 */
+			if ((priv->phy_ops->max_xfer_size == 0) ||
+			    (burstcnt <= priv->phy_ops->max_xfer_size))
+				return burstcnt;
+			if (retry_burstcnt)
+				return priv->phy_ops->max_xfer_size;
+			dev_warn(&chip->dev,
+				 "Bad burstcnt read: %d\n", burstcnt);
+			retry_burstcnt = true;
+		}
 		msleep(TPM_TIMEOUT);
 	} while (time_before(jiffies, stop));
 	return -EBUSY;
diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
index 9191aab..58e8b14 100644
--- a/drivers/char/tpm/tpm_tis_core.h
+++ b/drivers/char/tpm/tpm_tis_core.h
@@ -102,6 +102,7 @@ struct tpm_tis_phy_ops {
 	int (*read16)(struct tpm_tis_data *data, u32 addr, u16 *result);
 	int (*read32)(struct tpm_tis_data *data, u32 addr, u32 *result);
 	int (*write32)(struct tpm_tis_data *data, u32 addr, u32 src);
+	u16 max_xfer_size;
 };
 
 static inline int tpm_tis_read_bytes(struct tpm_tis_data *data, u32 addr,
-- 
2.6.6

WARNING: multiple messages have this Message-ID (diff)
From: Andrey Pronin <apronin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
To: Jarkko Sakkinen
	<jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Christophe Ricard
	<christophe.ricard-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: [PATCH v2 1/2] tpm_tis_core: add optional max xfer size check
Date: Tue, 19 Jul 2016 19:34:19 -0700	[thread overview]
Message-ID: <faf81974821d1748f671888afffba5721847aa6d.1468981325.git.apronin@chromium.org> (raw)
In-Reply-To: <cover.1468981325.git.apronin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
In-Reply-To: <cover.1468981325.git.apronin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

If tpm reports a bigger burstcnt than allowed by the physical protocol,
re-query the burstcnt and correct, if needed, if still too large.

In practice, seen in case of xfer issues (e.g. in spi interface case,
lost header causing flow control issues and wrong values returned on read
from TPM_STS). Without catching, causes the physical layer to reject xfer,
while is easily preventable by re-querying TPM_STS.

Signed-off-by: Andrey Pronin <apronin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 drivers/char/tpm/tpm_tis_core.c | 18 ++++++++++++++++--
 drivers/char/tpm/tpm_tis_core.h |  1 +
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index d66f51b..ffc1acb 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -158,6 +158,7 @@ static int get_burstcount(struct tpm_chip *chip)
 	unsigned long stop;
 	int burstcnt, rc;
 	u32 value;
+	bool retry_burstcnt = false;
 
 	/* wait for burstcount */
 	/* which timeout value, spec has 2 answers (c & d) */
@@ -168,8 +169,21 @@ static int get_burstcount(struct tpm_chip *chip)
 			return rc;
 
 		burstcnt = (value >> 8) & 0xFFFF;
-		if (burstcnt)
-			return burstcnt;
+		if (burstcnt) {
+			/* If burstcnt is larger than max allowed xfer
+			 * size, retry once - may be a glitch. Return
+			 * max_xfer_size on the 2nd try to avoid being
+			 * stuck forever.
+			 */
+			if ((priv->phy_ops->max_xfer_size == 0) ||
+			    (burstcnt <= priv->phy_ops->max_xfer_size))
+				return burstcnt;
+			if (retry_burstcnt)
+				return priv->phy_ops->max_xfer_size;
+			dev_warn(&chip->dev,
+				 "Bad burstcnt read: %d\n", burstcnt);
+			retry_burstcnt = true;
+		}
 		msleep(TPM_TIMEOUT);
 	} while (time_before(jiffies, stop));
 	return -EBUSY;
diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
index 9191aab..58e8b14 100644
--- a/drivers/char/tpm/tpm_tis_core.h
+++ b/drivers/char/tpm/tpm_tis_core.h
@@ -102,6 +102,7 @@ struct tpm_tis_phy_ops {
 	int (*read16)(struct tpm_tis_data *data, u32 addr, u16 *result);
 	int (*read32)(struct tpm_tis_data *data, u32 addr, u32 *result);
 	int (*write32)(struct tpm_tis_data *data, u32 addr, u32 src);
+	u16 max_xfer_size;
 };
 
 static inline int tpm_tis_read_bytes(struct tpm_tis_data *data, u32 addr,
-- 
2.6.6


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev

  reply	other threads:[~2016-07-20  2:34 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-15  1:39 [PATCH 0/2] tpm: add optional max xfer size check Andrey Pronin
2016-07-15  1:39 ` [PATCH 1/2] tpm_tis_core: " Andrey Pronin
2016-07-15  3:13   ` Jason Gunthorpe
2016-07-15  3:13     ` Jason Gunthorpe
2016-07-15  3:25     ` Andrey Pronin
2016-07-15  3:48       ` Guenter Roeck
2016-07-18 18:53     ` Jarkko Sakkinen
2016-07-18 18:53       ` Jarkko Sakkinen
2016-07-15  1:39 ` [PATCH 2/2] tpm_tis_spi: add max xfer size Andrey Pronin
2016-07-15  1:39   ` Andrey Pronin
2016-07-20  2:34 ` [PATCH v2 0/2] tpm: add optional max xfer size check Andrey Pronin
2016-07-20  2:34   ` Andrey Pronin
2016-07-20  2:34   ` Andrey Pronin [this message]
2016-07-20  2:34     ` [PATCH v2 1/2] tpm_tis_core: " Andrey Pronin
2016-07-20  2:34   ` [PATCH v2 2/2] tpm_tis_spi: add max xfer size Andrey Pronin
2016-07-20 15:10   ` [PATCH v2 0/2] tpm: add optional max xfer size check Jarkko Sakkinen
2016-07-20 15:10     ` Jarkko Sakkinen
2016-07-28  3:49 ` [PATCH v3 " Andrey Pronin
2016-07-28  3:49   ` Andrey Pronin
2016-07-28  3:49   ` [PATCH v3 1/2] tpm_tis_core: " Andrey Pronin
2016-07-28  3:49     ` Andrey Pronin
2016-07-28 22:52     ` Dmitry Torokhov
2016-08-09  8:14     ` Jarkko Sakkinen
2016-08-09  8:14       ` Jarkko Sakkinen
2020-11-19 10:00       ` Dafna Hirschfeld
2020-11-20 15:15         ` Jarkko Sakkinen
2016-07-28  3:49   ` [PATCH v3 2/2] tpm_tis_spi: add max xfer size Andrey Pronin
2016-07-28  3:49     ` Andrey Pronin
2016-07-28 22:53     ` Dmitry Torokhov
2016-08-09  8:14       ` Jarkko Sakkinen
2016-08-09  8:14         ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=faf81974821d1748f671888afffba5721847aa6d.1468981325.git.apronin@chromium.org \
    --to=apronin@chromium.org \
    --cc=christophe.ricard@gmail.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    --cc=tpmdd-devel@lists.sourceforge.net \
    --cc=tpmdd@selhorst.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.