From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Ed Swierk <eswierk@skyportsystems.com>
Cc: tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
jgunthorpe@obsidianresearch.com, stefanb@us.ibm.com
Subject: Re: [PATCH v7 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup
Date: Tue, 21 Jun 2016 23:55:53 +0300 [thread overview]
Message-ID: <20160621205553.GD8218@intel.com> (raw)
In-Reply-To: <1466474042-110773-6-git-send-email-eswierk@skyportsystems.com>
On Mon, Jun 20, 2016 at 06:54:02PM -0700, Ed Swierk wrote:
> The STMicro ST19NP18-TPM sometimes takes much longer to execute
> commands than it reports in its capabilities. For example, command 186
> (TPM_FlushSpecific) has been observed to take 14560 msec to complete,
> far longer than the 3000 msec limit for "short" commands reported by
> the chip. The behavior has also been seen with command 101
> (TPM_GetCapability).
>
> Worse, when the tpm_tis driver attempts to cancel the current command
> (by writing commandReady = 1 to TPM_STS_x), the chip locks up
> completely, returning all-1s from all memory-mapped register
> reads. The lockup can be cleared only by resetting the system.
>
> The occurrence of this excessive command duration depends on the
> sequence of commands preceding it. One sequence is creating at least 2
> new keys via TPM_CreateWrapKey, then letting the TPM idle for at least
> 30 seconds, then loading a key via TPM_LoadKey2. The next
> TPM_FlushSpecific occasionally takes tens of seconds to
> complete. Another sequence is creating many keys in a row without
> pause. The TPM_CreateWrapKey operation gets much slower after the
> first few iterations, as one would expect when the pool of precomputed
> keys is exhausted. Then after a 35-second pause, the same TPM_LoadKey2
> followed by TPM_FlushSpecific sequence triggers the behavior.
>
> Our working theory is that this older TPM sometimes pauses to
> precompute keys, which modern chips implement as a background
> process. Without access to the chip's implementation details it's
> impossible to know whether any commands are immune to being blocked by
> this process. So it seems safest to ignore the chip's reported command
> durations, and use a value much higher than any observed duration,
> like 180 sec (which is the duration this chip reports for "long"
> commands).
>
> Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
I think this fine but I would like to hear other opinions on this.
Stefan?
/Jarkko
> ---
> drivers/char/tpm/tpm_tis.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
> index caf7278..8355b45 100644
> --- a/drivers/char/tpm/tpm_tis.c
> +++ b/drivers/char/tpm/tpm_tis.c
> @@ -485,6 +485,12 @@ static void tpm_tis_update_timeouts(struct tpm_chip *chip)
> chip->vendor.timeout_d = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
> chip->vendor.timeout_adjusted = true;
> break;
> + case 0x0000104a: /* STMicro ST19NP18-TPM */
> + chip->vendor.duration[TPM_SHORT] = 180 * HZ;
> + chip->vendor.duration[TPM_MEDIUM] = 180 * HZ;
> + chip->vendor.duration[TPM_LONG] = 180 * HZ;
> + chip->vendor.duration_adjusted = true;
> + break;
> }
> }
>
> --
> 1.9.1
>
next prev parent reply other threads:[~2016-06-21 20:59 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-08 0:45 [PATCH v4 0/4] tpm: Command duration logging and chip-specific override Ed Swierk
2016-06-08 0:45 ` [PATCH v4 1/4] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-06-08 0:45 ` [PATCH v4 2/4] tpm: Add optional logging of TPM command durations Ed Swierk
2016-06-08 0:45 ` [PATCH v4 3/4] tpm: Allow TPM chip drivers to override reported " Ed Swierk
2016-06-08 19:05 ` [tpmdd-devel] " Jason Gunthorpe
2016-06-08 20:41 ` Ed Swierk
2016-06-08 0:45 ` [PATCH v4 4/4] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-06-08 23:00 ` [PATCH v5 0/4] tpm: Command duration logging and chip-specific override Ed Swierk
2016-06-08 23:00 ` [PATCH v5 1/4] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-06-08 23:00 ` [PATCH v5 2/4] tpm: Add optional logging of TPM command durations Ed Swierk
2016-06-08 23:00 ` [PATCH v5 3/4] tpm: Allow TPM chip drivers to override reported " Ed Swierk
2016-06-10 12:19 ` Jarkko Sakkinen
2016-06-10 17:34 ` Ed Swierk
2016-06-10 19:42 ` Jarkko Sakkinen
2016-06-11 1:54 ` Ed Swierk
2016-06-08 23:00 ` [PATCH v5 4/4] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-06-11 1:55 ` [PATCH v6 0/5] tpm: Command duration logging and chip-specific override Ed Swierk
2016-06-11 1:55 ` [PATCH v6 1/5] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-06-11 1:55 ` [PATCH v6 2/5] tpm: Add optional logging of TPM command durations Ed Swierk
2016-06-11 1:55 ` [PATCH v6 3/5] tpm: Factor out reading of timeout and duration capabilities Ed Swierk
2016-06-16 20:20 ` Jarkko Sakkinen
2016-06-19 12:12 ` Jarkko Sakkinen
2016-06-11 1:55 ` [PATCH v6 4/5] tpm: Allow TPM chip drivers to override reported command durations Ed Swierk
2016-06-16 20:26 ` Jarkko Sakkinen
2016-06-11 1:55 ` [PATCH v6 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-06-21 1:53 ` [PATCH v7 0/5] tpm: Command duration logging and chip-specific override Ed Swierk
2016-06-21 1:53 ` [PATCH v7 1/5] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-06-21 1:53 ` [PATCH v7 2/5] tpm: Add optional logging of TPM command durations Ed Swierk
2016-06-21 1:54 ` [PATCH v7 3/5] tpm: Clean up reading of timeout and duration capabilities Ed Swierk
2016-06-21 20:52 ` Jarkko Sakkinen
2016-06-22 0:21 ` Ed Swierk
2016-06-22 10:46 ` Jarkko Sakkinen
2016-06-21 1:54 ` [PATCH v7 4/5] tpm: Allow TPM chip drivers to override reported command durations Ed Swierk
2016-06-21 20:54 ` Jarkko Sakkinen
2016-06-21 1:54 ` [PATCH v7 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-06-21 20:55 ` Jarkko Sakkinen [this message]
2016-06-22 1:10 ` [PATCH v8 0/5] tpm: Command duration logging and chip-specific override Ed Swierk
2016-06-22 1:10 ` [PATCH v8 1/5] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-06-24 18:25 ` Jason Gunthorpe
2016-06-24 20:21 ` Jarkko Sakkinen
2016-06-24 20:23 ` Jarkko Sakkinen
2016-06-24 20:26 ` Jason Gunthorpe
2016-06-25 15:24 ` Jarkko Sakkinen
2016-06-25 15:47 ` Jarkko Sakkinen
2016-06-27 17:55 ` Jason Gunthorpe
2016-06-22 1:10 ` [PATCH v8 2/5] tpm: Add optional logging of TPM command durations Ed Swierk
2016-06-24 18:27 ` Jason Gunthorpe
2016-06-24 20:24 ` Jarkko Sakkinen
2016-06-22 1:10 ` [PATCH v8 3/5] tpm: Clean up reading of timeout and duration capabilities Ed Swierk
2016-06-22 1:10 ` [PATCH v8 4/5] tpm: Allow TPM chip drivers to override reported command durations Ed Swierk
2016-06-22 1:10 ` [PATCH v8 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-07-13 16:19 ` [PATCH v9 0/5] tpm: Command duration logging and chip-specific override Ed Swierk
2016-07-13 16:19 ` [PATCH v9 1/5] tpm_tis: Improve reporting of IO errors Ed Swierk
2016-07-13 16:19 ` [PATCH v9 2/5] tpm: Add optional logging of TPM command durations Ed Swierk
2016-07-13 16:19 ` [PATCH v9 3/5] tpm: Clean up reading of timeout and duration capabilities Ed Swierk
2016-07-18 18:15 ` Jarkko Sakkinen
2016-07-18 18:19 ` Jarkko Sakkinen
2016-07-18 18:20 ` Jarkko Sakkinen
2016-07-13 16:19 ` [PATCH v9 4/5] tpm: Allow TPM chip drivers to override reported command durations Ed Swierk
2016-07-13 17:04 ` kbuild test robot
2016-07-18 18:40 ` Jarkko Sakkinen
2016-07-13 16:19 ` [PATCH v9 5/5] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup Ed Swierk
2016-07-13 16:44 ` [PATCH v9 0/5] tpm: Command duration logging and chip-specific override Ed Swierk
2016-07-13 17:36 ` Jason Gunthorpe
2016-07-13 20:00 ` Ed Swierk
2016-07-13 20:58 ` Eric W. Biederman
2016-07-13 20:59 ` Jason Gunthorpe
2016-07-18 18:07 ` 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=20160621205553.GD8218@intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=eswierk@skyportsystems.com \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=stefanb@us.ibm.com \
--cc=tpmdd-devel@lists.sourceforge.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).