Louis will work on this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/trousers/+/2ba9706f576d1a0026ab1da6af9034b311683849

commit 2ba9706f576d1a0026ab1da6af9034b311683849
Author: Louis Collard <louiscollard@chromium.org>
Date: Fri Jun 01 10:51:57 2018

trousers: Retry I/O errors when communicating with the TPM.

Writes/reads will be retried up a number of times specified by the
TCSD_TPM_RW_RETRY_COUNT environment variable, or a default of 3
times if this is not set.

BUG=chromium:830130
TEST=ran live test locally with modified kernel that fails 50% of reads/writes, checks test passes and messages printed

Change-Id: I5a0d4d45bfa2ee415ac0c807883c679b5fdbf5b1
Reviewed-on: https://chromium-review.googlesource.com/1051489
Commit-Ready: Louis Collard <louiscollard@chromium.org>
Tested-by: Louis Collard <louiscollard@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>

[modify] https://crrev.com/2ba9706f576d1a0026ab1da6af9034b311683849/src/tddl/tddl.c

As analyzed in http://b/33758106#comment125, 

1) Low-level retries in tcsd from comment #3 don't cover all use cases. For authorized commands, if the comm issue happened when receiving a response, retrying the old command won't work (session nonce on TPM side has already changed). To cover those case we need retries for high-level ops, starting with launching the auth session.

2) for some platforms, we also have attestationd in tpm 1.2 case, so either we should switch to cryptohome-based attestation there; or implement high-level retries in attestationd as well (and that is still useful for 2.0 case).

ack, I'll revisit the high-level retries  work