Ed Swierk <eswi...@skyportsystems.com> wrote on 06/06/2016 06:27:59 PM:
>
> 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 750 msec limit for "short" commands reported by
> the chip. The behavior has also been seen with command 101
> (TPM_GetCapability).
Hm, those should be really fast.
>
> 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
How long does it take to create those keys? Maybe it will create new keys
in the 'background' after that.
> 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 perform
> internal garbage collection, 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
> this behavior. So it seems safest to ignore the chip's reported
> command durations, and use a value much higher than any observed
> duration, like 2 minutes (which happens to be the value used for
> TPM_UNDEFINED commands in tpm_calc_ordinal_duration()).
>
> v2: Minor correction of patch description.
>
> Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
Reviewed-by: Stefan Berger <stef...@linux.vnet.ibm.com>
------------------------------------------------------------------------------
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. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
