From: Amir Mizinski <amirmizi6@gmail.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Eyal.Cohen@nuvoton.com, oshrialkoby85@gmail.com,
alexander.steffen@infineon.com, robh+dt@kernel.org,
mark.rutland@arm.com, peterhuewe@gmx.de, jgg@ziepe.ca,
arnd@arndb.de, gregkh@linuxfoundation.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-integrity@vger.kernel.org, oshri.alkoby@nuvoton.com,
tmaimon77@gmail.com, gcwilson@us.ibm.com, kgoldman@us.ibm.com,
Dan.Morav@nuvoton.com, oren.tanami@nuvoton.com,
shmulik.hager@nuvoton.com, amir.mizinski@nuvoton.com,
Christophe Ricard <christophe-h.ricard@st.com>
Subject: Re: [PATCH v6 2/7] tpm: tpm_tis: Add check_data handle to tpm_tis_phy_ops
Date: Tue, 21 Apr 2020 13:34:44 +0000 [thread overview]
Message-ID: <0cfa0486-8ccb-d7d1-acf2-ca103f723b3a@gmail.com> (raw)
In-Reply-To: <20200408183324.GB33486@linux.intel.com>
Hello jarkko,
I reconfigure my email client by the instructions you've sent, and
re-responsing as you requested.
please tell me if there are still any issues. thank you.
On 2020-04-08 18:33, Jarkko Sakkinen wrote:
> On Tue, Apr 07, 2020 at 07:20:39PM +0300, amirmizi6@gmail.com wrote:
>> From: Amir Mizinski <amirmizi6@gmail.com>
>>
>> In order to validate data integrity we need to compute the crc over the data
>> sent in lower layer (I2C for instance).
>
> s/crc/CRC/
>
>> To do that tpm_tis_check_data() calls a "check_data" operation (if available).
>
> "check_data" does not exist.
>
it is added in this commit to "tpm_tis_phy_ops" struct in
"tpm_tis_core.h", which is inherited in "tpm_tis_i2c.c" on later patch
(7/7).
>> If data integrity check fails, a retry to save the sent/received
>> data is implemented in tpm_tis_send_main()/tpm_tis_recv() functions.
>>
>> Considering this commit, the following steps are done when sending a command:
>> 1. Host writes to TPM_STS.commandReady.
>> 2. Host writes command.
>> 3. Host checks that TPM received data is valid.
>> 4. If data is currupted go to step 1.
>>
>> When receiving data:
>> 1. Host checks that TPM_STS.dataAvail is set.
>> 2. Host saves received data.
>> 3. Host checks that received data is correct.
>> 4. If data is currupted Host writes to TPM_STS.responseRetry and go to
>> step 1.
>
> These sequences in the commit message look somewhat uselss. Maybe
> just remove them.
>
Their main porpose is to describe how the retry attempt is implemented
in case of currupted data.
should i just describe that with a few words or that's unnecessary?
>>
>> Co-developed-by: Christophe Ricard <christophe-h.ricard@st.com>
>> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
>> Signed-off-by: Amir Mizinski <amirmizi6@gmail.com>
>> ---
>> drivers/char/tpm/tpm_tis_core.c | 102 +++++++++++++++++++++++++---------------
>> drivers/char/tpm/tpm_tis_core.h | 3 ++
>> 2 files changed, 67 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
>> index 27c6ca0..6c4f232 100644
>> --- a/drivers/char/tpm/tpm_tis_core.c
>> +++ b/drivers/char/tpm/tpm_tis_core.c
>> @@ -242,6 +242,15 @@ static u8 tpm_tis_status(struct tpm_chip *chip)
>> return status;
>> }
>>
>> +static bool tpm_tis_check_data(struct tpm_chip *chip, const u8 *buf, size_t len)
>
> Not sure if this is the best possible function name, "check" can
> mean almost anything.
>
Ok, i'm changing it to "verify_data_integrity". is that ok?
>> +{
>> + struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev);
>> +
>> + if (priv->phy_ops->check_data)
>> + return priv->phy_ops->check_data(priv, buf, len);
>
> New line here before the return statement.
>
>> + return true;
>> +}
>> +
>> static void tpm_tis_ready(struct tpm_chip *chip)
>> {
>> struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev);
>> @@ -308,47 +317,59 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, size_t count)
>> {
>> struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev);
>> int size = 0;
>> - int status;
>> + int status, i;
>> u32 expected;
>> + bool check_data = false;
>>
>> - if (count < TPM_HEADER_SIZE) {
>> - size = -EIO;
>> - goto out;
>> - }
>> + for (i = 0; i < TPM_RETRY; i++) {
>> + if (count < TPM_HEADER_SIZE) {
>> + size = -EIO;
>> + goto out;
>> + }
>>
>> - size = recv_data(chip, buf, TPM_HEADER_SIZE);
>> - /* read first 10 bytes, including tag, paramsize, and result */
>> - if (size < TPM_HEADER_SIZE) {
>> - dev_err(&chip->dev, "Unable to read header\n");
>> - goto out;
>> - }
>> + size = recv_data(chip, buf, TPM_HEADER_SIZE);
>> + /* read first 10 bytes, including tag, paramsize, and result */
>> + if (size < TPM_HEADER_SIZE) {
>> + dev_err(&chip->dev, "Unable to read header\n");
>> + goto out;
>> + }
>>
>> - expected = be32_to_cpu(*(__be32 *) (buf + 2));
>> - if (expected > count || expected < TPM_HEADER_SIZE) {
>> - size = -EIO;
>> - goto out;
>> - }
>> + expected = be32_to_cpu(*(__be32 *) (buf + 2));
>> + if (expected > count || expected < TPM_HEADER_SIZE) {
>> + size = -EIO;
>> + goto out;
>> + }
>>
>> - size += recv_data(chip, &buf[TPM_HEADER_SIZE],
>> - expected - TPM_HEADER_SIZE);
>> - if (size < expected) {
>> - dev_err(&chip->dev, "Unable to read remainder of result\n");
>> - size = -ETIME;
>> - goto out;
>> - }
>> + size += recv_data(chip, &buf[TPM_HEADER_SIZE],
>> + expected - TPM_HEADER_SIZE);
>> + if (size < expected) {
>> + dev_err(&chip->dev, "Unable to read remainder of result\n");
>> + size = -ETIME;
>> + goto out;
>> + }
>>
>> - if (wait_for_tpm_stat(chip, TPM_STS_VALID, chip->timeout_c,
>> - &priv->int_queue, false) < 0) {
>> - size = -ETIME;
>> - goto out;
>> + if (wait_for_tpm_stat(chip, TPM_STS_VALID, chip->timeout_c,
>> + &priv->int_queue, false) < 0) {
>> + size = -ETIME;
>> + goto out;
>> + }
>> +
>> + status = tpm_tis_status(chip);
>> + if (status & TPM_STS_DATA_AVAIL) { /* retry? */
>> + dev_err(&chip->dev, "Error left over data\n");
>> + size = -EIO;
>> + goto out;
>> + }
>> +
>> + check_data = tpm_tis_check_data(chip, buf, size);
>> + if (!check_data)
>> + tpm_tis_write8(priv, TPM_STS(priv->locality),
>> + TPM_STS_RESPONSE_RETRY);
>> + else
>> + break;
>> }
>> - status = tpm_tis_status(chip);
>> - if (status & TPM_STS_DATA_AVAIL) { /* retry? */
>> - dev_err(&chip->dev, "Error left over data\n");
>> + if (!check_data)
>> size = -EIO;
>> - goto out;
>> - }
>> -
>> out:
>> tpm_tis_ready(chip);
>> return size;
>> @@ -453,14 +474,19 @@ static void disable_interrupts(struct tpm_chip *chip)
>> static int tpm_tis_send_main(struct tpm_chip *chip, const u8 *buf, size_t len)
>> {
>> struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev);
>> - int rc;
>> + int rc, i;
>> u32 ordinal;
>> unsigned long dur;
>> + bool data_valid = false;
>>
>> - rc = tpm_tis_send_data(chip, buf, len);
>> - if (rc < 0)
>> - return rc;
>> -
>> + for (i = 0; i < TPM_RETRY && !data_valid; i++) {
>> + rc = tpm_tis_send_data(chip, buf, len);
>> + if (rc < 0)
>> + return rc;
>> + data_valid = tpm_tis_check_data(chip, buf, len);
>> + }
>> + if (!data_valid)
>> + return -EIO;
>> /* go and do it */
>> rc = tpm_tis_write8(priv, TPM_STS(priv->locality), TPM_STS_GO);
>> if (rc < 0)
>> diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
>> index d06c65b..486c2e9 100644
>> --- a/drivers/char/tpm/tpm_tis_core.h
>> +++ b/drivers/char/tpm/tpm_tis_core.h
>> @@ -34,6 +34,7 @@ enum tis_status {
>> TPM_STS_GO = 0x20,
>> TPM_STS_DATA_AVAIL = 0x10,
>> TPM_STS_DATA_EXPECT = 0x08,
>> + TPM_STS_RESPONSE_RETRY = 0x02,
>> };
>>
>> enum tis_int_flags {
>> @@ -106,6 +107,8 @@ 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);
>> + bool (*check_data)(struct tpm_tis_data *data, const u8 *buf,
>> + size_t len);
>
> Aren't you validating the contents of the buf?
>
> /Jarkko
i do.
when sending, the data is written to the buff in "tpm_tis_send_data(chip,buf, len)".
and validated in "data_valid = tpm_tis_check_data(chip, buf, len)".
data is not sent until TPM_STS_GO is set.
when receiving, the data in the buffer is verified after recv_data, and
writing to TPM_STS_RESPONSE_RETRY in case it fails to recive it again.
Thank you
Amir Mizinski
next prev parent reply other threads:[~2020-04-21 13:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-07 16:20 [PATCH v6 0/7] Add tpm i2c ptp driver amirmizi6
2020-04-07 16:20 ` [PATCH v6 1/7] tpm: tpm_tis: Make implementation of read16 read32 write32 optional amirmizi6
2020-04-08 16:46 ` Jarkko Sakkinen
2020-04-07 16:20 ` [PATCH v6 2/7] tpm: tpm_tis: Add check_data handle to tpm_tis_phy_ops amirmizi6
2020-04-08 18:33 ` Jarkko Sakkinen
[not found] ` <CAMHTsUUzQ9rpPfsnEtJruAC3THr+XNA=5Wk7OCteqZXOQ0L=UA@mail.gmail.com>
2020-04-12 13:53 ` Jarkko Sakkinen
2020-04-21 13:34 ` Amir Mizinski [this message]
2020-04-21 20:19 ` Jarkko Sakkinen
2020-04-07 16:20 ` [PATCH v6 3/7] tpm: tpm_tis: rewrite "tpm_tis_req_canceled()" amirmizi6
2020-04-07 16:20 ` [PATCH v6 4/7] tpm: tpm_tis: Fix expected bit handling and send all bytes in one shot without last byte in exception amirmizi6
2020-04-07 16:20 ` [PATCH v6 5/7] tpm: Handle an exception for TPM Firmware Update mode amirmizi6
2020-04-07 16:20 ` [PATCH v6 6/7] dt-bindings: tpm: Add YAML schema for TPM TIS I2C options amirmizi6
2020-04-15 15:20 ` Rob Herring
2020-04-22 8:15 ` Amir Mizinski
2020-04-07 16:20 ` [PATCH v6 7/7] tpm: tpm_tis: add tpm_tis_i2c driver amirmizi6
2020-04-08 18:36 ` 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=0cfa0486-8ccb-d7d1-acf2-ca103f723b3a@gmail.com \
--to=amirmizi6@gmail.com \
--cc=Dan.Morav@nuvoton.com \
--cc=Eyal.Cohen@nuvoton.com \
--cc=alexander.steffen@infineon.com \
--cc=amir.mizinski@nuvoton.com \
--cc=arnd@arndb.de \
--cc=christophe-h.ricard@st.com \
--cc=devicetree@vger.kernel.org \
--cc=gcwilson@us.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jgg@ziepe.ca \
--cc=kgoldman@us.ibm.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=oren.tanami@nuvoton.com \
--cc=oshri.alkoby@nuvoton.com \
--cc=oshrialkoby85@gmail.com \
--cc=peterhuewe@gmx.de \
--cc=robh+dt@kernel.org \
--cc=shmulik.hager@nuvoton.com \
--cc=tmaimon77@gmail.com \
/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).