From: Mimi Zohar <zohar@linux.ibm.com>
To: Benoit HOUYERE <benoit.houyere@st.com>,
Omar Sandoval <osandov@osandov.com>,
Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Peter Huewe <peterhuewe@gmx.de>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
"kernel-team@fb.com" <kernel-team@fb.com>
Subject: Re: [PATCH v2] tpm_tis: work around status register bug in STMicroelectronics TPM
Date: Tue, 21 Apr 2020 18:17:10 -0400 [thread overview]
Message-ID: <1587507430.5053.16.camel@linux.ibm.com> (raw)
In-Reply-To: <3766ead79aa4415198bc5a8324f02f6e@SFHDAG3NODE3.st.com>
On Tue, 2020-04-21 at 20:56 +0000, Benoit HOUYERE wrote:
> Issue occurs on several legacy models and corrected on latest TPM
> versions. Several corrections are possible. Omar's proposal is quite
> simple, short and efficient. Penalty time is only condition check
> but for all TPM_status access.
>
> Other possibility is to check status register validity (bit 5 is
> always at 0) at the first reading and modify wait_for_stat function
> (already inserted for I2C patch).
Benoit, thank you for the explanation.
It sounds like by "already inserted for I2C patch", you mean that this
proposed solution is part of the i2c patch set. If that is the case,
to simplify backporting, the fix should be the first patch in the i2c
patch set.
Mimi
next prev parent reply other threads:[~2020-04-21 22:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-16 0:23 [PATCH v2] tpm_tis: work around status register bug in STMicroelectronics TPM Omar Sandoval
2020-04-16 6:22 ` Paul Menzel
2020-04-16 19:02 ` Omar Sandoval
2020-04-20 22:36 ` Ken Goldman
2020-04-21 13:44 ` Mimi Zohar
2020-04-21 20:56 ` Benoit HOUYERE
2020-04-21 22:17 ` Mimi Zohar [this message]
2020-04-21 22:22 ` Benoit HOUYERE
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=1587507430.5053.16.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=benoit.houyere@st.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jgg@ziepe.ca \
--cc=kernel-team@fb.com \
--cc=linux-integrity@vger.kernel.org \
--cc=osandov@osandov.com \
--cc=peterhuewe@gmx.de \
--cc=pmenzel@molgen.mpg.de \
/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).