* [PATCH 0/2] Unify send() callbacks
@ 2019-02-08 14:05 Jarkko Sakkinen
2019-02-08 14:05 ` [PATCH 1/2] tpm: Unify the send callback behaviour Jarkko Sakkinen
2019-02-08 14:06 ` [PATCH 2/2] tpm/tpm_i2c_atmel: Return -E2BIG when the transfer is incomplete Jarkko Sakkinen
0 siblings, 2 replies; 10+ messages in thread
From: Jarkko Sakkinen @ 2019-02-08 14:05 UTC (permalink / raw)
To: linux-integrity
Cc: linux-kernel, linux-security-module, Peter Huewe,
Jason Gunthorpe, Stefan Berger, Nayna Jain, Jarkko Sakkinen
A portion of send() callbacks have returned length, in many cases just
returning back what was given as an argument, and tpm_crb has returned 0 on
success. This patch set fixes and unifies the behaviour.
Jarkko Sakkinen (2):
tpm: Unify the send callback behaviour
tpm/tpm_i2c_atmel: Return -E2BIG when the transfer is incomplete
drivers/char/tpm/st33zp24/st33zp24.c | 2 +-
drivers/char/tpm/tpm_atmel.c | 2 +-
drivers/char/tpm/tpm_i2c_atmel.c | 10 +++++++++-
drivers/char/tpm/tpm_i2c_infineon.c | 2 +-
drivers/char/tpm/tpm_i2c_nuvoton.c | 2 +-
drivers/char/tpm/tpm_ibmvtpm.c | 2 +-
drivers/char/tpm/tpm_vtpm_proxy.c | 3 +--
drivers/char/tpm/xen-tpmfront.c | 2 +-
8 files changed, 16 insertions(+), 9 deletions(-)
--
2.19.1
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 1/2] tpm: Unify the send callback behaviour
2019-02-08 14:05 [PATCH 0/2] Unify send() callbacks Jarkko Sakkinen
@ 2019-02-08 14:05 ` Jarkko Sakkinen
2019-02-08 14:42 ` Stefan Berger
2019-02-08 14:06 ` [PATCH 2/2] tpm/tpm_i2c_atmel: Return -E2BIG when the transfer is incomplete Jarkko Sakkinen
1 sibling, 1 reply; 10+ messages in thread
From: Jarkko Sakkinen @ 2019-02-08 14:05 UTC (permalink / raw)
To: linux-integrity
Cc: linux-kernel, linux-security-module, Peter Huewe,
Jason Gunthorpe, Stefan Berger, Nayna Jain, Jarkko Sakkinen,
stable
The send() callback should never return length as it does not in every
driver except tpm_crb in the success case. The reason is that the main
transmit functionality only cares about whether the transmit was
successful or not and ignores the count completely.
Cc: stable@vger.kernel.org
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
drivers/char/tpm/st33zp24/st33zp24.c | 2 +-
drivers/char/tpm/tpm_atmel.c | 2 +-
drivers/char/tpm/tpm_i2c_atmel.c | 6 +++++-
drivers/char/tpm/tpm_i2c_infineon.c | 2 +-
drivers/char/tpm/tpm_i2c_nuvoton.c | 2 +-
drivers/char/tpm/tpm_ibmvtpm.c | 2 +-
drivers/char/tpm/tpm_vtpm_proxy.c | 3 +--
drivers/char/tpm/xen-tpmfront.c | 2 +-
8 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/char/tpm/st33zp24/st33zp24.c b/drivers/char/tpm/st33zp24/st33zp24.c
index 64dc560859f2..13dc614b7ebc 100644
--- a/drivers/char/tpm/st33zp24/st33zp24.c
+++ b/drivers/char/tpm/st33zp24/st33zp24.c
@@ -436,7 +436,7 @@ static int st33zp24_send(struct tpm_chip *chip, unsigned char *buf,
goto out_err;
}
- return len;
+ return 0;
out_err:
st33zp24_cancel(chip);
release_locality(chip);
diff --git a/drivers/char/tpm/tpm_atmel.c b/drivers/char/tpm/tpm_atmel.c
index 66a14526aaf4..a290b30a0c35 100644
--- a/drivers/char/tpm/tpm_atmel.c
+++ b/drivers/char/tpm/tpm_atmel.c
@@ -105,7 +105,7 @@ static int tpm_atml_send(struct tpm_chip *chip, u8 *buf, size_t count)
iowrite8(buf[i], priv->iobase);
}
- return count;
+ return 0;
}
static void tpm_atml_cancel(struct tpm_chip *chip)
diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
index 4720b2442ffe..aa11c8a1df5e 100644
--- a/drivers/char/tpm/tpm_i2c_atmel.c
+++ b/drivers/char/tpm/tpm_i2c_atmel.c
@@ -65,7 +65,11 @@ static int i2c_atmel_send(struct tpm_chip *chip, u8 *buf, size_t len)
dev_dbg(&chip->dev,
"%s(buf=%*ph len=%0zx) -> sts=%d\n", __func__,
(int)min_t(size_t, 64, len), buf, len, status);
- return status;
+
+ if (status < 0)
+ return status;
+
+ return 0;
}
static int i2c_atmel_recv(struct tpm_chip *chip, u8 *buf, size_t count)
diff --git a/drivers/char/tpm/tpm_i2c_infineon.c b/drivers/char/tpm/tpm_i2c_infineon.c
index 3b490d9d90e7..3b4e9672ff6c 100644
--- a/drivers/char/tpm/tpm_i2c_infineon.c
+++ b/drivers/char/tpm/tpm_i2c_infineon.c
@@ -588,7 +588,7 @@ static int tpm_tis_i2c_send(struct tpm_chip *chip, u8 *buf, size_t len)
/* go and do it */
iic_tpm_write(TPM_STS(tpm_dev.locality), &sts, 1);
- return len;
+ return 0;
out_err:
tpm_tis_i2c_ready(chip);
/* The TPM needs some time to clean up here,
diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c b/drivers/char/tpm/tpm_i2c_nuvoton.c
index 5700cc2ddee1..315a3b4548f7 100644
--- a/drivers/char/tpm/tpm_i2c_nuvoton.c
+++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
@@ -465,7 +465,7 @@ static int i2c_nuvoton_send(struct tpm_chip *chip, u8 *buf, size_t len)
}
dev_dbg(dev, "%s() -> %zd\n", __func__, len);
- return len;
+ return 0;
}
static bool i2c_nuvoton_req_canceled(struct tpm_chip *chip, u8 status)
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 07b5a487d0c8..aeae3222723c 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -192,7 +192,7 @@ static int tpm_ibmvtpm_send(struct tpm_chip *chip, u8 *buf, size_t count)
rc = 0;
ibmvtpm->tpm_processing_cmd = false;
} else
- rc = count;
+ rc = 0;
spin_unlock(&ibmvtpm->rtce_lock);
return rc;
diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c b/drivers/char/tpm/tpm_vtpm_proxy.c
index 26a2be555288..d74f3de74ae6 100644
--- a/drivers/char/tpm/tpm_vtpm_proxy.c
+++ b/drivers/char/tpm/tpm_vtpm_proxy.c
@@ -335,7 +335,6 @@ static int vtpm_proxy_is_driver_command(struct tpm_chip *chip,
static int vtpm_proxy_tpm_op_send(struct tpm_chip *chip, u8 *buf, size_t count)
{
struct proxy_dev *proxy_dev = dev_get_drvdata(&chip->dev);
- int rc = 0;
if (count > sizeof(proxy_dev->buffer)) {
dev_err(&chip->dev,
@@ -366,7 +365,7 @@ static int vtpm_proxy_tpm_op_send(struct tpm_chip *chip, u8 *buf, size_t count)
wake_up_interruptible(&proxy_dev->wq);
- return rc;
+ return 0;
}
static void vtpm_proxy_tpm_op_cancel(struct tpm_chip *chip)
diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
index 1259e935fd58..4e2d00cb0d81 100644
--- a/drivers/char/tpm/xen-tpmfront.c
+++ b/drivers/char/tpm/xen-tpmfront.c
@@ -173,7 +173,7 @@ static int vtpm_send(struct tpm_chip *chip, u8 *buf, size_t count)
return -ETIME;
}
- return count;
+ return 0;
}
static int vtpm_recv(struct tpm_chip *chip, u8 *buf, size_t count)
--
2.19.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH 2/2] tpm/tpm_i2c_atmel: Return -E2BIG when the transfer is incomplete
2019-02-08 14:05 [PATCH 0/2] Unify send() callbacks Jarkko Sakkinen
2019-02-08 14:05 ` [PATCH 1/2] tpm: Unify the send callback behaviour Jarkko Sakkinen
@ 2019-02-08 14:06 ` Jarkko Sakkinen
1 sibling, 0 replies; 10+ messages in thread
From: Jarkko Sakkinen @ 2019-02-08 14:06 UTC (permalink / raw)
To: linux-integrity
Cc: linux-kernel, linux-security-module, Peter Huewe,
Jason Gunthorpe, Stefan Berger, Nayna Jain, Jarkko Sakkinen,
stable
Return -E2BIG when the transfer is incomplete. The upper layer does
not retry, so not doing that is incorrect behaviour.
Cc: stable@vger.kernel.org
Fixes: a2871c62e186 ("tpm: Add support for Atmel I2C TPMs")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
drivers/char/tpm/tpm_i2c_atmel.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
index aa11c8a1df5e..8a7e80923091 100644
--- a/drivers/char/tpm/tpm_i2c_atmel.c
+++ b/drivers/char/tpm/tpm_i2c_atmel.c
@@ -69,6 +69,10 @@ static int i2c_atmel_send(struct tpm_chip *chip, u8 *buf, size_t len)
if (status < 0)
return status;
+ /* The upper layer does not support incomplete sends. */
+ if (status != len)
+ return -E2BIG;
+
return 0;
}
--
2.19.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] tpm: Unify the send callback behaviour
2019-02-08 14:05 ` [PATCH 1/2] tpm: Unify the send callback behaviour Jarkko Sakkinen
@ 2019-02-08 14:42 ` Stefan Berger
2019-02-08 15:42 ` Jarkko Sakkinen
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Berger @ 2019-02-08 14:42 UTC (permalink / raw)
To: Jarkko Sakkinen, linux-integrity
Cc: linux-kernel, linux-security-module, Peter Huewe,
Jason Gunthorpe, Stefan Berger, Nayna Jain, stable
On 2/8/19 9:05 AM, Jarkko Sakkinen wrote:
> The send() callback should never return length as it does not in every
> driver except tpm_crb in the success case. The reason is that the main
> transmit functionality only cares about whether the transmit was
> successful or not and ignores the count completely.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
> drivers/char/tpm/st33zp24/st33zp24.c | 2 +-
> drivers/char/tpm/tpm_atmel.c | 2 +-
> drivers/char/tpm/tpm_i2c_atmel.c | 6 +++++-
> drivers/char/tpm/tpm_i2c_infineon.c | 2 +-
> drivers/char/tpm/tpm_i2c_nuvoton.c | 2 +-
> drivers/char/tpm/tpm_ibmvtpm.c | 2 +-
> drivers/char/tpm/tpm_vtpm_proxy.c | 3 +--
> drivers/char/tpm/xen-tpmfront.c | 2 +-
At least tpm_nsc_send (tpm_nsc.c) and tpm_inf_send (tpm_infineon.c) are
also returning the number of bytes sent. I would consider tpm_crb the
outlier that returns 0 and should return the length even though we don't
need it...
> 8 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/char/tpm/st33zp24/st33zp24.c b/drivers/char/tpm/st33zp24/st33zp24.c
> index 64dc560859f2..13dc614b7ebc 100644
> --- a/drivers/char/tpm/st33zp24/st33zp24.c
> +++ b/drivers/char/tpm/st33zp24/st33zp24.c
> @@ -436,7 +436,7 @@ static int st33zp24_send(struct tpm_chip *chip, unsigned char *buf,
> goto out_err;
> }
>
> - return len;
> + return 0;
> out_err:
> st33zp24_cancel(chip);
> release_locality(chip);
> diff --git a/drivers/char/tpm/tpm_atmel.c b/drivers/char/tpm/tpm_atmel.c
> index 66a14526aaf4..a290b30a0c35 100644
> --- a/drivers/char/tpm/tpm_atmel.c
> +++ b/drivers/char/tpm/tpm_atmel.c
> @@ -105,7 +105,7 @@ static int tpm_atml_send(struct tpm_chip *chip, u8 *buf, size_t count)
> iowrite8(buf[i], priv->iobase);
> }
>
> - return count;
> + return 0;
> }
>
> static void tpm_atml_cancel(struct tpm_chip *chip)
> diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
> index 4720b2442ffe..aa11c8a1df5e 100644
> --- a/drivers/char/tpm/tpm_i2c_atmel.c
> +++ b/drivers/char/tpm/tpm_i2c_atmel.c
> @@ -65,7 +65,11 @@ static int i2c_atmel_send(struct tpm_chip *chip, u8 *buf, size_t len)
> dev_dbg(&chip->dev,
> "%s(buf=%*ph len=%0zx) -> sts=%d\n", __func__,
> (int)min_t(size_t, 64, len), buf, len, status);
> - return status;
> +
> + if (status < 0)
> + return status;
> +
> + return 0;
> }
>
> static int i2c_atmel_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> diff --git a/drivers/char/tpm/tpm_i2c_infineon.c b/drivers/char/tpm/tpm_i2c_infineon.c
> index 3b490d9d90e7..3b4e9672ff6c 100644
> --- a/drivers/char/tpm/tpm_i2c_infineon.c
> +++ b/drivers/char/tpm/tpm_i2c_infineon.c
> @@ -588,7 +588,7 @@ static int tpm_tis_i2c_send(struct tpm_chip *chip, u8 *buf, size_t len)
> /* go and do it */
> iic_tpm_write(TPM_STS(tpm_dev.locality), &sts, 1);
>
> - return len;
> + return 0;
> out_err:
> tpm_tis_i2c_ready(chip);
> /* The TPM needs some time to clean up here,
> diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c b/drivers/char/tpm/tpm_i2c_nuvoton.c
> index 5700cc2ddee1..315a3b4548f7 100644
> --- a/drivers/char/tpm/tpm_i2c_nuvoton.c
> +++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
> @@ -465,7 +465,7 @@ static int i2c_nuvoton_send(struct tpm_chip *chip, u8 *buf, size_t len)
> }
>
> dev_dbg(dev, "%s() -> %zd\n", __func__, len);
> - return len;
> + return 0;
> }
>
> static bool i2c_nuvoton_req_canceled(struct tpm_chip *chip, u8 status)
> diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
> index 07b5a487d0c8..aeae3222723c 100644
> --- a/drivers/char/tpm/tpm_ibmvtpm.c
> +++ b/drivers/char/tpm/tpm_ibmvtpm.c
> @@ -192,7 +192,7 @@ static int tpm_ibmvtpm_send(struct tpm_chip *chip, u8 *buf, size_t count)
> rc = 0;
> ibmvtpm->tpm_processing_cmd = false;
> } else
> - rc = count;
> + rc = 0;
>
> spin_unlock(&ibmvtpm->rtce_lock);
> return rc;
> diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c b/drivers/char/tpm/tpm_vtpm_proxy.c
> index 26a2be555288..d74f3de74ae6 100644
> --- a/drivers/char/tpm/tpm_vtpm_proxy.c
> +++ b/drivers/char/tpm/tpm_vtpm_proxy.c
> @@ -335,7 +335,6 @@ static int vtpm_proxy_is_driver_command(struct tpm_chip *chip,
> static int vtpm_proxy_tpm_op_send(struct tpm_chip *chip, u8 *buf, size_t count)
> {
> struct proxy_dev *proxy_dev = dev_get_drvdata(&chip->dev);
> - int rc = 0;
>
> if (count > sizeof(proxy_dev->buffer)) {
> dev_err(&chip->dev,
> @@ -366,7 +365,7 @@ static int vtpm_proxy_tpm_op_send(struct tpm_chip *chip, u8 *buf, size_t count)
>
> wake_up_interruptible(&proxy_dev->wq);
>
> - return rc;
> + return 0;
> }
>
> static void vtpm_proxy_tpm_op_cancel(struct tpm_chip *chip)
> diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
> index 1259e935fd58..4e2d00cb0d81 100644
> --- a/drivers/char/tpm/xen-tpmfront.c
> +++ b/drivers/char/tpm/xen-tpmfront.c
> @@ -173,7 +173,7 @@ static int vtpm_send(struct tpm_chip *chip, u8 *buf, size_t count)
> return -ETIME;
> }
>
> - return count;
> + return 0;
> }
>
> static int vtpm_recv(struct tpm_chip *chip, u8 *buf, size_t count)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] tpm: Unify the send callback behaviour
2019-02-08 14:42 ` Stefan Berger
@ 2019-02-08 15:42 ` Jarkko Sakkinen
2019-02-08 15:45 ` Stefan Berger
0 siblings, 1 reply; 10+ messages in thread
From: Jarkko Sakkinen @ 2019-02-08 15:42 UTC (permalink / raw)
To: Stefan Berger
Cc: linux-integrity, linux-kernel, linux-security-module,
Peter Huewe, Jason Gunthorpe, Stefan Berger, Nayna Jain, stable
On Fri, Feb 08, 2019 at 09:42:16AM -0500, Stefan Berger wrote: > On 2/8/19 9:05 AM, Jarkko Sakkinen wrote:
> At least tpm_nsc_send (tpm_nsc.c) and tpm_inf_send (tpm_infineon.c) are also
> returning the number of bytes sent. I would consider tpm_crb the outlier
> that returns 0 and should return the length even though we don't need it...
That would be absolutely wrong way the fix the *actual* issue i.e.
callbacks returning garbage (sometimes just passing the length parameter
back as a return value).
/Jarkko
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] tpm: Unify the send callback behaviour
2019-02-08 15:42 ` Jarkko Sakkinen
@ 2019-02-08 15:45 ` Stefan Berger
2019-02-08 16:07 ` Jarkko Sakkinen
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Berger @ 2019-02-08 15:45 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: linux-integrity, linux-kernel, linux-security-module,
Peter Huewe, Jason Gunthorpe, Stefan Berger, Nayna Jain, stable
On 2/8/19 10:42 AM, Jarkko Sakkinen wrote:
> On Fri, Feb 08, 2019 at 09:42:16AM -0500, Stefan Berger wrote: > On 2/8/19 9:05 AM, Jarkko Sakkinen wrote:
>> At least tpm_nsc_send (tpm_nsc.c) and tpm_inf_send (tpm_infineon.c) are also
>> returning the number of bytes sent. I would consider tpm_crb the outlier
>> that returns 0 and should return the length even though we don't need it...
> That would be absolutely wrong way the fix the *actual* issue i.e.
> callbacks returning garbage (sometimes just passing the length parameter
> back as a return value).
Then I guess you have to fixes those other two files as well...
>
> /Jarkko
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] tpm: Unify the send callback behaviour
2019-02-08 15:45 ` Stefan Berger
@ 2019-02-08 16:07 ` Jarkko Sakkinen
2019-02-08 16:19 ` Stefan Berger
0 siblings, 1 reply; 10+ messages in thread
From: Jarkko Sakkinen @ 2019-02-08 16:07 UTC (permalink / raw)
To: Stefan Berger
Cc: linux-integrity, linux-kernel, linux-security-module,
Peter Huewe, Jason Gunthorpe, Stefan Berger, Nayna Jain, stable
On Fri, Feb 08, 2019 at 10:45:53AM -0500, Stefan Berger wrote:
> On 2/8/19 10:42 AM, Jarkko Sakkinen wrote:
> > On Fri, Feb 08, 2019 at 09:42:16AM -0500, Stefan Berger wrote: > On 2/8/19 9:05 AM, Jarkko Sakkinen wrote:
> > > At least tpm_nsc_send (tpm_nsc.c) and tpm_inf_send (tpm_infineon.c) are also
> > > returning the number of bytes sent. I would consider tpm_crb the outlier
> > > that returns 0 and should return the length even though we don't need it...
> > That would be absolutely wrong way the fix the *actual* issue i.e.
> > callbacks returning garbage (sometimes just passing the length parameter
> > back as a return value).
>
> Then I guess you have to fixes those other two files as well...
That's still a better option.
/Jarkko
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] tpm: Unify the send callback behaviour
2019-02-08 16:07 ` Jarkko Sakkinen
@ 2019-02-08 16:19 ` Stefan Berger
2019-02-08 16:26 ` Jarkko Sakkinen
0 siblings, 1 reply; 10+ messages in thread
From: Stefan Berger @ 2019-02-08 16:19 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: linux-integrity, linux-kernel, linux-security-module,
Peter Huewe, Jason Gunthorpe, Stefan Berger, Nayna Jain, stable
On 2/8/19 11:07 AM, Jarkko Sakkinen wrote:
> On Fri, Feb 08, 2019 at 10:45:53AM -0500, Stefan Berger wrote:
>> On 2/8/19 10:42 AM, Jarkko Sakkinen wrote:
>>> On Fri, Feb 08, 2019 at 09:42:16AM -0500, Stefan Berger wrote: > On 2/8/19 9:05 AM, Jarkko Sakkinen wrote:
>>>> At least tpm_nsc_send (tpm_nsc.c) and tpm_inf_send (tpm_infineon.c) are also
>>>> returning the number of bytes sent. I would consider tpm_crb the outlier
>>>> that returns 0 and should return the length even though we don't need it...
>>> That would be absolutely wrong way the fix the *actual* issue i.e.
>>> callbacks returning garbage (sometimes just passing the length parameter
>>> back as a return value).
>> Then I guess you have to fixes those other two files as well...
> That's still a better option.
tpm_tis_core.c's tpm_tis_send_main() also needs fixing...
>
> /Jarkko
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] tpm: Unify the send callback behaviour
2019-02-08 16:19 ` Stefan Berger
@ 2019-02-08 16:26 ` Jarkko Sakkinen
2019-02-08 16:28 ` Jarkko Sakkinen
0 siblings, 1 reply; 10+ messages in thread
From: Jarkko Sakkinen @ 2019-02-08 16:26 UTC (permalink / raw)
To: Stefan Berger
Cc: linux-integrity, linux-kernel, linux-security-module,
Peter Huewe, Jason Gunthorpe, Stefan Berger, Nayna Jain, stable
On Fri, Feb 08, 2019 at 11:19:04AM -0500, Stefan Berger wrote:
> On 2/8/19 11:07 AM, Jarkko Sakkinen wrote:
> > On Fri, Feb 08, 2019 at 10:45:53AM -0500, Stefan Berger wrote:
> > > On 2/8/19 10:42 AM, Jarkko Sakkinen wrote:
> > > > On Fri, Feb 08, 2019 at 09:42:16AM -0500, Stefan Berger wrote: > On 2/8/19 9:05 AM, Jarkko Sakkinen wrote:
> > > > > At least tpm_nsc_send (tpm_nsc.c) and tpm_inf_send (tpm_infineon.c) are also
> > > > > returning the number of bytes sent. I would consider tpm_crb the outlier
> > > > > that returns 0 and should return the length even though we don't need it...
> > > > That would be absolutely wrong way the fix the *actual* issue i.e.
> > > > callbacks returning garbage (sometimes just passing the length parameter
> > > > back as a return value).
> > > Then I guess you have to fixes those other two files as well...
> > That's still a better option.
>
> tpm_tis_core.c's tpm_tis_send_main() also needs fixing...
Weird I had that fixed in my working area. Probably somehow managed
not to stage that change. It was like the very first things that
I fixed. Updating..
/Jarkko
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 1/2] tpm: Unify the send callback behaviour
2019-02-08 16:26 ` Jarkko Sakkinen
@ 2019-02-08 16:28 ` Jarkko Sakkinen
0 siblings, 0 replies; 10+ messages in thread
From: Jarkko Sakkinen @ 2019-02-08 16:28 UTC (permalink / raw)
To: Stefan Berger
Cc: linux-integrity, linux-kernel, linux-security-module,
Peter Huewe, Jason Gunthorpe, Stefan Berger, Nayna Jain, stable
On Fri, Feb 08, 2019 at 06:26:15PM +0200, Jarkko Sakkinen wrote:
> On Fri, Feb 08, 2019 at 11:19:04AM -0500, Stefan Berger wrote:
> > On 2/8/19 11:07 AM, Jarkko Sakkinen wrote:
> > > On Fri, Feb 08, 2019 at 10:45:53AM -0500, Stefan Berger wrote:
> > > > On 2/8/19 10:42 AM, Jarkko Sakkinen wrote:
> > > > > On Fri, Feb 08, 2019 at 09:42:16AM -0500, Stefan Berger wrote: > On 2/8/19 9:05 AM, Jarkko Sakkinen wrote:
> > > > > > At least tpm_nsc_send (tpm_nsc.c) and tpm_inf_send (tpm_infineon.c) are also
> > > > > > returning the number of bytes sent. I would consider tpm_crb the outlier
> > > > > > that returns 0 and should return the length even though we don't need it...
> > > > > That would be absolutely wrong way the fix the *actual* issue i.e.
> > > > > callbacks returning garbage (sometimes just passing the length parameter
> > > > > back as a return value).
> > > > Then I guess you have to fixes those other two files as well...
> > > That's still a better option.
> >
> > tpm_tis_core.c's tpm_tis_send_main() also needs fixing...
>
> Weird I had that fixed in my working area. Probably somehow managed
> not to stage that change. It was like the very first things that
> I fixed. Updating..
tpm_tis_send() would be the right function.
/Jarkko
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-02-08 16:28 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-08 14:05 [PATCH 0/2] Unify send() callbacks Jarkko Sakkinen
2019-02-08 14:05 ` [PATCH 1/2] tpm: Unify the send callback behaviour Jarkko Sakkinen
2019-02-08 14:42 ` Stefan Berger
2019-02-08 15:42 ` Jarkko Sakkinen
2019-02-08 15:45 ` Stefan Berger
2019-02-08 16:07 ` Jarkko Sakkinen
2019-02-08 16:19 ` Stefan Berger
2019-02-08 16:26 ` Jarkko Sakkinen
2019-02-08 16:28 ` Jarkko Sakkinen
2019-02-08 14:06 ` [PATCH 2/2] tpm/tpm_i2c_atmel: Return -E2BIG when the transfer is incomplete Jarkko Sakkinen
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).