* [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
@ 2017-05-07 17:50 ` Jarkko Sakkinen
0 siblings, 0 replies; 20+ messages in thread
From: Jarkko Sakkinen @ 2017-05-07 17:50 UTC (permalink / raw)
To: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Cc: open list, linux-security-module-u79uwXL29TY76Z2rM5mHXA
You should not do arithmetic with __be32 or __le32 types because
sometimes it results incorrect results. Calculations must be done only
with integers that are in in the CPU byte order. This commit migrates
tpm_getcap() to struct tpm_buf in order to sort out these issues.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
Now this should work as Robertos patches move byte order conversion
where it should be. Sadly I'm out of reach to my Dell E6400 laptop
that I use for TPM 1.2 testing.
drivers/char/tpm/tpm-interface.c | 30 ++++++++++++++++--------------
drivers/char/tpm/tpm.h | 13 -------------
2 files changed, 16 insertions(+), 27 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 4ed08ab4d2a8..7436422458c7 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -552,31 +552,33 @@ static const struct tpm_input_header tpm_getcap_header = {
ssize_t tpm_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
const char *desc, size_t min_cap_length)
{
- struct tpm_cmd_t tpm_cmd;
+ struct tpm_buf buf;
int rc;
- tpm_cmd.header.in = tpm_getcap_header;
+ rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_GET_CAP);
+ if (rc)
+ return rc;
+
if (subcap_id == TPM_CAP_VERSION_1_1 ||
subcap_id == TPM_CAP_VERSION_1_2) {
- tpm_cmd.params.getcap_in.cap = cpu_to_be32(subcap_id);
- /*subcap field not necessary */
- tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0);
- tpm_cmd.header.in.length -= cpu_to_be32(sizeof(__be32));
+ tpm_buf_append_u32(&buf, subcap_id);
+ tpm_buf_append_u32(&buf, 0);
} else {
if (subcap_id == TPM_CAP_FLAG_PERM ||
subcap_id == TPM_CAP_FLAG_VOL)
- tpm_cmd.params.getcap_in.cap =
- cpu_to_be32(TPM_CAP_FLAG);
+ tpm_buf_append_u32(&buf, TPM_CAP_FLAG);
else
- tpm_cmd.params.getcap_in.cap =
- cpu_to_be32(TPM_CAP_PROP);
- tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
- tpm_cmd.params.getcap_in.subcap = cpu_to_be32(subcap_id);
+ tpm_buf_append_u32(&buf, TPM_CAP_PROP);
+
+ tpm_buf_append_u32(&buf, 4);
+ tpm_buf_append_u32(&buf, subcap_id);
}
- rc = tpm_transmit_cmd(chip, NULL, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
+ rc = tpm_transmit_cmd(chip, NULL, buf.data, TPM_INTERNAL_RESULT_SIZE,
min_cap_length, 0, desc);
if (!rc)
- *cap = tpm_cmd.params.getcap_out.cap;
+ *cap = *(cap_t *)&buf.data[TPM_HEADER_SIZE + 4];
+
+ tpm_buf_destroy(&buf);
return rc;
}
EXPORT_SYMBOL_GPL(tpm_getcap);
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index e81d8c7acb39..dd1173427fb2 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -339,17 +339,6 @@ enum tpm_sub_capabilities {
TPM_CAP_PROP_TIS_DURATION = 0x120,
};
-struct tpm_getcap_params_in {
- __be32 cap;
- __be32 subcap_size;
- __be32 subcap;
-} __packed;
-
-struct tpm_getcap_params_out {
- __be32 cap_size;
- cap_t cap;
-} __packed;
-
struct tpm_readpubek_params_out {
u8 algorithm[4];
u8 encscheme[2];
@@ -399,10 +388,8 @@ struct tpm_startup_in {
} __packed;
typedef union {
- struct tpm_getcap_params_out getcap_out;
struct tpm_readpubek_params_out readpubek_out;
u8 readpubek_out_buffer[sizeof(struct tpm_readpubek_params_out)];
- struct tpm_getcap_params_in getcap_in;
struct tpm_pcrread_in pcrread_in;
struct tpm_pcrread_out pcrread_out;
struct tpm_pcrextend_in pcrextend_in;
--
2.11.0
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply related [flat|nested] 20+ messages in thread* [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
@ 2017-05-07 17:50 ` Jarkko Sakkinen
0 siblings, 0 replies; 20+ messages in thread
From: Jarkko Sakkinen @ 2017-05-07 17:50 UTC (permalink / raw)
To: linux-security-module
You should not do arithmetic with __be32 or __le32 types because
sometimes it results incorrect results. Calculations must be done only
with integers that are in in the CPU byte order. This commit migrates
tpm_getcap() to struct tpm_buf in order to sort out these issues.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
Now this should work as Robertos patches move byte order conversion
where it should be. Sadly I'm out of reach to my Dell E6400 laptop
that I use for TPM 1.2 testing.
drivers/char/tpm/tpm-interface.c | 30 ++++++++++++++++--------------
drivers/char/tpm/tpm.h | 13 -------------
2 files changed, 16 insertions(+), 27 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 4ed08ab4d2a8..7436422458c7 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -552,31 +552,33 @@ static const struct tpm_input_header tpm_getcap_header = {
ssize_t tpm_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
const char *desc, size_t min_cap_length)
{
- struct tpm_cmd_t tpm_cmd;
+ struct tpm_buf buf;
int rc;
- tpm_cmd.header.in = tpm_getcap_header;
+ rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_GET_CAP);
+ if (rc)
+ return rc;
+
if (subcap_id == TPM_CAP_VERSION_1_1 ||
subcap_id == TPM_CAP_VERSION_1_2) {
- tpm_cmd.params.getcap_in.cap = cpu_to_be32(subcap_id);
- /*subcap field not necessary */
- tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0);
- tpm_cmd.header.in.length -= cpu_to_be32(sizeof(__be32));
+ tpm_buf_append_u32(&buf, subcap_id);
+ tpm_buf_append_u32(&buf, 0);
} else {
if (subcap_id == TPM_CAP_FLAG_PERM ||
subcap_id == TPM_CAP_FLAG_VOL)
- tpm_cmd.params.getcap_in.cap =
- cpu_to_be32(TPM_CAP_FLAG);
+ tpm_buf_append_u32(&buf, TPM_CAP_FLAG);
else
- tpm_cmd.params.getcap_in.cap =
- cpu_to_be32(TPM_CAP_PROP);
- tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
- tpm_cmd.params.getcap_in.subcap = cpu_to_be32(subcap_id);
+ tpm_buf_append_u32(&buf, TPM_CAP_PROP);
+
+ tpm_buf_append_u32(&buf, 4);
+ tpm_buf_append_u32(&buf, subcap_id);
}
- rc = tpm_transmit_cmd(chip, NULL, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
+ rc = tpm_transmit_cmd(chip, NULL, buf.data, TPM_INTERNAL_RESULT_SIZE,
min_cap_length, 0, desc);
if (!rc)
- *cap = tpm_cmd.params.getcap_out.cap;
+ *cap = *(cap_t *)&buf.data[TPM_HEADER_SIZE + 4];
+
+ tpm_buf_destroy(&buf);
return rc;
}
EXPORT_SYMBOL_GPL(tpm_getcap);
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index e81d8c7acb39..dd1173427fb2 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -339,17 +339,6 @@ enum tpm_sub_capabilities {
TPM_CAP_PROP_TIS_DURATION = 0x120,
};
-struct tpm_getcap_params_in {
- __be32 cap;
- __be32 subcap_size;
- __be32 subcap;
-} __packed;
-
-struct tpm_getcap_params_out {
- __be32 cap_size;
- cap_t cap;
-} __packed;
-
struct tpm_readpubek_params_out {
u8 algorithm[4];
u8 encscheme[2];
@@ -399,10 +388,8 @@ struct tpm_startup_in {
} __packed;
typedef union {
- struct tpm_getcap_params_out getcap_out;
struct tpm_readpubek_params_out readpubek_out;
u8 readpubek_out_buffer[sizeof(struct tpm_readpubek_params_out)];
- struct tpm_getcap_params_in getcap_in;
struct tpm_pcrread_in pcrread_in;
struct tpm_pcrread_out pcrread_out;
struct tpm_pcrextend_in pcrextend_in;
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
2017-05-07 17:50 ` Jarkko Sakkinen
@ 2017-05-09 14:13 ` Jarkko Sakkinen
-1 siblings, 0 replies; 20+ messages in thread
From: Jarkko Sakkinen @ 2017-05-09 14:13 UTC (permalink / raw)
To: tpmdd-devel
Cc: linux-security-module, Peter Huewe, Marcel Selhorst,
Jason Gunthorpe, open list
On Sun, May 07, 2017 at 08:50:02PM +0300, Jarkko Sakkinen wrote:
> You should not do arithmetic with __be32 or __le32 types because
> sometimes it results incorrect results. Calculations must be done only
> with integers that are in in the CPU byte order. This commit migrates
> tpm_getcap() to struct tpm_buf in order to sort out these issues.
>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
> Now this should work as Robertos patches move byte order conversion
> where it should be. Sadly I'm out of reach to my Dell E6400 laptop
> that I use for TPM 1.2 testing.
> drivers/char/tpm/tpm-interface.c | 30 ++++++++++++++++--------------
> drivers/char/tpm/tpm.h | 13 -------------
> 2 files changed, 16 insertions(+), 27 deletions(-)
I've now tested this with TPM 1.2. Any complains?
/Jarkko
> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
> index 4ed08ab4d2a8..7436422458c7 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -552,31 +552,33 @@ static const struct tpm_input_header tpm_getcap_header = {
> ssize_t tpm_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
> const char *desc, size_t min_cap_length)
> {
> - struct tpm_cmd_t tpm_cmd;
> + struct tpm_buf buf;
> int rc;
>
> - tpm_cmd.header.in = tpm_getcap_header;
> + rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_GET_CAP);
> + if (rc)
> + return rc;
> +
> if (subcap_id == TPM_CAP_VERSION_1_1 ||
> subcap_id == TPM_CAP_VERSION_1_2) {
> - tpm_cmd.params.getcap_in.cap = cpu_to_be32(subcap_id);
> - /*subcap field not necessary */
> - tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0);
> - tpm_cmd.header.in.length -= cpu_to_be32(sizeof(__be32));
> + tpm_buf_append_u32(&buf, subcap_id);
> + tpm_buf_append_u32(&buf, 0);
> } else {
> if (subcap_id == TPM_CAP_FLAG_PERM ||
> subcap_id == TPM_CAP_FLAG_VOL)
> - tpm_cmd.params.getcap_in.cap =
> - cpu_to_be32(TPM_CAP_FLAG);
> + tpm_buf_append_u32(&buf, TPM_CAP_FLAG);
> else
> - tpm_cmd.params.getcap_in.cap =
> - cpu_to_be32(TPM_CAP_PROP);
> - tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
> - tpm_cmd.params.getcap_in.subcap = cpu_to_be32(subcap_id);
> + tpm_buf_append_u32(&buf, TPM_CAP_PROP);
> +
> + tpm_buf_append_u32(&buf, 4);
> + tpm_buf_append_u32(&buf, subcap_id);
> }
> - rc = tpm_transmit_cmd(chip, NULL, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
> + rc = tpm_transmit_cmd(chip, NULL, buf.data, TPM_INTERNAL_RESULT_SIZE,
> min_cap_length, 0, desc);
> if (!rc)
> - *cap = tpm_cmd.params.getcap_out.cap;
> + *cap = *(cap_t *)&buf.data[TPM_HEADER_SIZE + 4];
> +
> + tpm_buf_destroy(&buf);
> return rc;
> }
> EXPORT_SYMBOL_GPL(tpm_getcap);
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index e81d8c7acb39..dd1173427fb2 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -339,17 +339,6 @@ enum tpm_sub_capabilities {
> TPM_CAP_PROP_TIS_DURATION = 0x120,
> };
>
> -struct tpm_getcap_params_in {
> - __be32 cap;
> - __be32 subcap_size;
> - __be32 subcap;
> -} __packed;
> -
> -struct tpm_getcap_params_out {
> - __be32 cap_size;
> - cap_t cap;
> -} __packed;
> -
> struct tpm_readpubek_params_out {
> u8 algorithm[4];
> u8 encscheme[2];
> @@ -399,10 +388,8 @@ struct tpm_startup_in {
> } __packed;
>
> typedef union {
> - struct tpm_getcap_params_out getcap_out;
> struct tpm_readpubek_params_out readpubek_out;
> u8 readpubek_out_buffer[sizeof(struct tpm_readpubek_params_out)];
> - struct tpm_getcap_params_in getcap_in;
> struct tpm_pcrread_in pcrread_in;
> struct tpm_pcrread_out pcrread_out;
> struct tpm_pcrextend_in pcrextend_in;
> --
> 2.11.0
>
^ permalink raw reply [flat|nested] 20+ messages in thread* [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
@ 2017-05-09 14:13 ` Jarkko Sakkinen
0 siblings, 0 replies; 20+ messages in thread
From: Jarkko Sakkinen @ 2017-05-09 14:13 UTC (permalink / raw)
To: linux-security-module
On Sun, May 07, 2017 at 08:50:02PM +0300, Jarkko Sakkinen wrote:
> You should not do arithmetic with __be32 or __le32 types because
> sometimes it results incorrect results. Calculations must be done only
> with integers that are in in the CPU byte order. This commit migrates
> tpm_getcap() to struct tpm_buf in order to sort out these issues.
>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
> Now this should work as Robertos patches move byte order conversion
> where it should be. Sadly I'm out of reach to my Dell E6400 laptop
> that I use for TPM 1.2 testing.
> drivers/char/tpm/tpm-interface.c | 30 ++++++++++++++++--------------
> drivers/char/tpm/tpm.h | 13 -------------
> 2 files changed, 16 insertions(+), 27 deletions(-)
I've now tested this with TPM 1.2. Any complains?
/Jarkko
> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
> index 4ed08ab4d2a8..7436422458c7 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -552,31 +552,33 @@ static const struct tpm_input_header tpm_getcap_header = {
> ssize_t tpm_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
> const char *desc, size_t min_cap_length)
> {
> - struct tpm_cmd_t tpm_cmd;
> + struct tpm_buf buf;
> int rc;
>
> - tpm_cmd.header.in = tpm_getcap_header;
> + rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_GET_CAP);
> + if (rc)
> + return rc;
> +
> if (subcap_id == TPM_CAP_VERSION_1_1 ||
> subcap_id == TPM_CAP_VERSION_1_2) {
> - tpm_cmd.params.getcap_in.cap = cpu_to_be32(subcap_id);
> - /*subcap field not necessary */
> - tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0);
> - tpm_cmd.header.in.length -= cpu_to_be32(sizeof(__be32));
> + tpm_buf_append_u32(&buf, subcap_id);
> + tpm_buf_append_u32(&buf, 0);
> } else {
> if (subcap_id == TPM_CAP_FLAG_PERM ||
> subcap_id == TPM_CAP_FLAG_VOL)
> - tpm_cmd.params.getcap_in.cap =
> - cpu_to_be32(TPM_CAP_FLAG);
> + tpm_buf_append_u32(&buf, TPM_CAP_FLAG);
> else
> - tpm_cmd.params.getcap_in.cap =
> - cpu_to_be32(TPM_CAP_PROP);
> - tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
> - tpm_cmd.params.getcap_in.subcap = cpu_to_be32(subcap_id);
> + tpm_buf_append_u32(&buf, TPM_CAP_PROP);
> +
> + tpm_buf_append_u32(&buf, 4);
> + tpm_buf_append_u32(&buf, subcap_id);
> }
> - rc = tpm_transmit_cmd(chip, NULL, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
> + rc = tpm_transmit_cmd(chip, NULL, buf.data, TPM_INTERNAL_RESULT_SIZE,
> min_cap_length, 0, desc);
> if (!rc)
> - *cap = tpm_cmd.params.getcap_out.cap;
> + *cap = *(cap_t *)&buf.data[TPM_HEADER_SIZE + 4];
> +
> + tpm_buf_destroy(&buf);
> return rc;
> }
> EXPORT_SYMBOL_GPL(tpm_getcap);
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index e81d8c7acb39..dd1173427fb2 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -339,17 +339,6 @@ enum tpm_sub_capabilities {
> TPM_CAP_PROP_TIS_DURATION = 0x120,
> };
>
> -struct tpm_getcap_params_in {
> - __be32 cap;
> - __be32 subcap_size;
> - __be32 subcap;
> -} __packed;
> -
> -struct tpm_getcap_params_out {
> - __be32 cap_size;
> - cap_t cap;
> -} __packed;
> -
> struct tpm_readpubek_params_out {
> u8 algorithm[4];
> u8 encscheme[2];
> @@ -399,10 +388,8 @@ struct tpm_startup_in {
> } __packed;
>
> typedef union {
> - struct tpm_getcap_params_out getcap_out;
> struct tpm_readpubek_params_out readpubek_out;
> u8 readpubek_out_buffer[sizeof(struct tpm_readpubek_params_out)];
> - struct tpm_getcap_params_in getcap_in;
> struct tpm_pcrread_in pcrread_in;
> struct tpm_pcrread_out pcrread_out;
> struct tpm_pcrextend_in pcrextend_in;
> --
> 2.11.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
2017-05-09 14:13 ` Jarkko Sakkinen
@ 2017-05-09 15:13 ` Jason Gunthorpe
-1 siblings, 0 replies; 20+ messages in thread
From: Jason Gunthorpe @ 2017-05-09 15:13 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: tpmdd-devel, linux-security-module, Peter Huewe, Marcel Selhorst,
open list
On Tue, May 09, 2017 at 05:13:53PM +0300, Jarkko Sakkinen wrote:
> On Sun, May 07, 2017 at 08:50:02PM +0300, Jarkko Sakkinen wrote:
> > You should not do arithmetic with __be32 or __le32 types because
> > sometimes it results incorrect results. Calculations must be done only
> > with integers that are in in the CPU byte order. This commit migrates
> > tpm_getcap() to struct tpm_buf in order to sort out these issues.
> >
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > Now this should work as Robertos patches move byte order conversion
> > where it should be. Sadly I'm out of reach to my Dell E6400 laptop
> > that I use for TPM 1.2 testing.
> > drivers/char/tpm/tpm-interface.c | 30 ++++++++++++++++--------------
> > drivers/char/tpm/tpm.h | 13 -------------
> > 2 files changed, 16 insertions(+), 27 deletions(-)
>
> I've now tested this with TPM 1.2. Any complains?
Seems reasonable, but which linke had the problematic arithmetic?
Jason
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
@ 2017-05-09 15:13 ` Jason Gunthorpe
0 siblings, 0 replies; 20+ messages in thread
From: Jason Gunthorpe @ 2017-05-09 15:13 UTC (permalink / raw)
To: linux-security-module
On Tue, May 09, 2017 at 05:13:53PM +0300, Jarkko Sakkinen wrote:
> On Sun, May 07, 2017 at 08:50:02PM +0300, Jarkko Sakkinen wrote:
> > You should not do arithmetic with __be32 or __le32 types because
> > sometimes it results incorrect results. Calculations must be done only
> > with integers that are in in the CPU byte order. This commit migrates
> > tpm_getcap() to struct tpm_buf in order to sort out these issues.
> >
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > Now this should work as Robertos patches move byte order conversion
> > where it should be. Sadly I'm out of reach to my Dell E6400 laptop
> > that I use for TPM 1.2 testing.
> > drivers/char/tpm/tpm-interface.c | 30 ++++++++++++++++--------------
> > drivers/char/tpm/tpm.h | 13 -------------
> > 2 files changed, 16 insertions(+), 27 deletions(-)
>
> I've now tested this with TPM 1.2. Any complains?
Seems reasonable, but which linke had the problematic arithmetic?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
2017-05-09 15:13 ` Jason Gunthorpe
@ 2017-05-10 12:34 ` Jarkko Sakkinen
-1 siblings, 0 replies; 20+ messages in thread
From: Jarkko Sakkinen @ 2017-05-10 12:34 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: tpmdd-devel, linux-security-module, Peter Huewe, Marcel Selhorst,
open list
On Tue, May 09, 2017 at 09:13:08AM -0600, Jason Gunthorpe wrote:
> On Tue, May 09, 2017 at 05:13:53PM +0300, Jarkko Sakkinen wrote:
> > On Sun, May 07, 2017 at 08:50:02PM +0300, Jarkko Sakkinen wrote:
> > > You should not do arithmetic with __be32 or __le32 types because
> > > sometimes it results incorrect results. Calculations must be done only
> > > with integers that are in in the CPU byte order. This commit migrates
> > > tpm_getcap() to struct tpm_buf in order to sort out these issues.
> > >
> > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > > Now this should work as Robertos patches move byte order conversion
> > > where it should be. Sadly I'm out of reach to my Dell E6400 laptop
> > > that I use for TPM 1.2 testing.
> > > drivers/char/tpm/tpm-interface.c | 30 ++++++++++++++++--------------
> > > drivers/char/tpm/tpm.h | 13 -------------
> > > 2 files changed, 16 insertions(+), 27 deletions(-)
> >
> > I've now tested this with TPM 1.2. Any complains?
>
> Seems reasonable, but which linke had the problematic arithmetic?
>
> Jason
Arithmetic should work but it's not a good practice to do additions,
substractions or multiplications in any other byte order than the CPU
byte order.
sparse also complains about this.
/Jarkko
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
@ 2017-05-10 12:34 ` Jarkko Sakkinen
0 siblings, 0 replies; 20+ messages in thread
From: Jarkko Sakkinen @ 2017-05-10 12:34 UTC (permalink / raw)
To: linux-security-module
On Tue, May 09, 2017 at 09:13:08AM -0600, Jason Gunthorpe wrote:
> On Tue, May 09, 2017 at 05:13:53PM +0300, Jarkko Sakkinen wrote:
> > On Sun, May 07, 2017 at 08:50:02PM +0300, Jarkko Sakkinen wrote:
> > > You should not do arithmetic with __be32 or __le32 types because
> > > sometimes it results incorrect results. Calculations must be done only
> > > with integers that are in in the CPU byte order. This commit migrates
> > > tpm_getcap() to struct tpm_buf in order to sort out these issues.
> > >
> > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > > Now this should work as Robertos patches move byte order conversion
> > > where it should be. Sadly I'm out of reach to my Dell E6400 laptop
> > > that I use for TPM 1.2 testing.
> > > drivers/char/tpm/tpm-interface.c | 30 ++++++++++++++++--------------
> > > drivers/char/tpm/tpm.h | 13 -------------
> > > 2 files changed, 16 insertions(+), 27 deletions(-)
> >
> > I've now tested this with TPM 1.2. Any complains?
>
> Seems reasonable, but which linke had the problematic arithmetic?
>
> Jason
Arithmetic should work but it's not a good practice to do additions,
substractions or multiplications in any other byte order than the CPU
byte order.
sparse also complains about this.
/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
2017-05-10 12:34 ` Jarkko Sakkinen
@ 2017-05-10 23:41 ` Luc Van Oostenryck
-1 siblings, 0 replies; 20+ messages in thread
From: Luc Van Oostenryck @ 2017-05-10 23:41 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Jason Gunthorpe, tpmdd-devel, linux-security-module, Peter Huewe,
Marcel Selhorst, open list
On Wed, May 10, 2017 at 2:34 PM, Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
> Arithmetic should work but it's not a good practice to do additions,
> substractions or multiplications in any other byte order than the CPU
> byte order.
>
> sparse also complains about this.
>
> /Jarkko
Arithmetic should work?
let's try with 0x0080:
in native order: 0x0080 + 0x0080 = 0x0100
in reverse order: 0x8000 + 0x8000 = 0x0000 != swap16(0x0100)
Or do I misunderstand what you mean by "arithmetic should work"?
-- Luc Van Oostenryck
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
@ 2017-05-10 23:41 ` Luc Van Oostenryck
0 siblings, 0 replies; 20+ messages in thread
From: Luc Van Oostenryck @ 2017-05-10 23:41 UTC (permalink / raw)
To: linux-security-module
On Wed, May 10, 2017 at 2:34 PM, Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
> Arithmetic should work but it's not a good practice to do additions,
> substractions or multiplications in any other byte order than the CPU
> byte order.
>
> sparse also complains about this.
>
> /Jarkko
Arithmetic should work?
let's try with 0x0080:
in native order: 0x0080 + 0x0080 = 0x0100
in reverse order: 0x8000 + 0x8000 = 0x0000 != swap16(0x0100)
Or do I misunderstand what you mean by "arithmetic should work"?
-- Luc Van Oostenryck
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
2017-05-10 23:41 ` Luc Van Oostenryck
@ 2017-05-11 10:16 ` Jarkko Sakkinen
-1 siblings, 0 replies; 20+ messages in thread
From: Jarkko Sakkinen @ 2017-05-11 10:16 UTC (permalink / raw)
To: Luc Van Oostenryck
Cc: Jason Gunthorpe, tpmdd-devel, linux-security-module, Peter Huewe,
Marcel Selhorst, open list
On Thu, May 11, 2017 at 01:41:15AM +0200, Luc Van Oostenryck wrote:
> On Wed, May 10, 2017 at 2:34 PM, Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
>
> > Arithmetic should work but it's not a good practice to do additions,
> > substractions or multiplications in any other byte order than the CPU
> > byte order.
> >
> > sparse also complains about this.
> >
> > /Jarkko
>
> Arithmetic should work?
> let's try with 0x0080:
> in native order: 0x0080 + 0x0080 = 0x0100
> in reverse order: 0x8000 + 0x8000 = 0x0000 != swap16(0x0100)
>
> Or do I misunderstand what you mean by "arithmetic should work"?
>
> -- Luc Van Oostenryck
I was referring to the specific code snippet in tpm-interface.c.
/Jarkko
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
@ 2017-05-11 10:16 ` Jarkko Sakkinen
0 siblings, 0 replies; 20+ messages in thread
From: Jarkko Sakkinen @ 2017-05-11 10:16 UTC (permalink / raw)
To: linux-security-module
On Thu, May 11, 2017 at 01:41:15AM +0200, Luc Van Oostenryck wrote:
> On Wed, May 10, 2017 at 2:34 PM, Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
>
> > Arithmetic should work but it's not a good practice to do additions,
> > substractions or multiplications in any other byte order than the CPU
> > byte order.
> >
> > sparse also complains about this.
> >
> > /Jarkko
>
> Arithmetic should work?
> let's try with 0x0080:
> in native order: 0x0080 + 0x0080 = 0x0100
> in reverse order: 0x8000 + 0x8000 = 0x0000 != swap16(0x0100)
>
> Or do I misunderstand what you mean by "arithmetic should work"?
>
> -- Luc Van Oostenryck
I was referring to the specific code snippet in tpm-interface.c.
/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [tpmdd-devel] [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
2017-05-10 12:34 ` Jarkko Sakkinen
@ 2017-05-15 11:36 ` Jarkko Sakkinen
-1 siblings, 0 replies; 20+ messages in thread
From: Jarkko Sakkinen @ 2017-05-15 11:36 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-security-module, tpmdd-devel, open list
On Wed, May 10, 2017 at 03:34:58PM +0300, Jarkko Sakkinen wrote:
> On Tue, May 09, 2017 at 09:13:08AM -0600, Jason Gunthorpe wrote:
> > On Tue, May 09, 2017 at 05:13:53PM +0300, Jarkko Sakkinen wrote:
> > > On Sun, May 07, 2017 at 08:50:02PM +0300, Jarkko Sakkinen wrote:
> > > > You should not do arithmetic with __be32 or __le32 types because
> > > > sometimes it results incorrect results. Calculations must be done only
> > > > with integers that are in in the CPU byte order. This commit migrates
> > > > tpm_getcap() to struct tpm_buf in order to sort out these issues.
> > > >
> > > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > > > Now this should work as Robertos patches move byte order conversion
> > > > where it should be. Sadly I'm out of reach to my Dell E6400 laptop
> > > > that I use for TPM 1.2 testing.
> > > > drivers/char/tpm/tpm-interface.c | 30 ++++++++++++++++--------------
> > > > drivers/char/tpm/tpm.h | 13 -------------
> > > > 2 files changed, 16 insertions(+), 27 deletions(-)
> > >
> > > I've now tested this with TPM 1.2. Any complains?
> >
> > Seems reasonable, but which linke had the problematic arithmetic?
> >
> > Jason
>
> Arithmetic should work but it's not a good practice to do additions,
> substractions or multiplications in any other byte order than the CPU
> byte order.
>
> sparse also complains about this.
Can I get your Reviewed-by for this one?
/Jarkko
^ permalink raw reply [flat|nested] 20+ messages in thread
* [tpmdd-devel] [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
@ 2017-05-15 11:36 ` Jarkko Sakkinen
0 siblings, 0 replies; 20+ messages in thread
From: Jarkko Sakkinen @ 2017-05-15 11:36 UTC (permalink / raw)
To: linux-security-module
On Wed, May 10, 2017 at 03:34:58PM +0300, Jarkko Sakkinen wrote:
> On Tue, May 09, 2017 at 09:13:08AM -0600, Jason Gunthorpe wrote:
> > On Tue, May 09, 2017 at 05:13:53PM +0300, Jarkko Sakkinen wrote:
> > > On Sun, May 07, 2017 at 08:50:02PM +0300, Jarkko Sakkinen wrote:
> > > > You should not do arithmetic with __be32 or __le32 types because
> > > > sometimes it results incorrect results. Calculations must be done only
> > > > with integers that are in in the CPU byte order. This commit migrates
> > > > tpm_getcap() to struct tpm_buf in order to sort out these issues.
> > > >
> > > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > > > Now this should work as Robertos patches move byte order conversion
> > > > where it should be. Sadly I'm out of reach to my Dell E6400 laptop
> > > > that I use for TPM 1.2 testing.
> > > > drivers/char/tpm/tpm-interface.c | 30 ++++++++++++++++--------------
> > > > drivers/char/tpm/tpm.h | 13 -------------
> > > > 2 files changed, 16 insertions(+), 27 deletions(-)
> > >
> > > I've now tested this with TPM 1.2. Any complains?
> >
> > Seems reasonable, but which linke had the problematic arithmetic?
> >
> > Jason
>
> Arithmetic should work but it's not a good practice to do additions,
> substractions or multiplications in any other byte order than the CPU
> byte order.
>
> sparse also complains about this.
Can I get your Reviewed-by for this one?
/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [tpmdd-devel] [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
2017-05-15 11:36 ` Jarkko Sakkinen
@ 2017-05-15 15:39 ` Jason Gunthorpe
-1 siblings, 0 replies; 20+ messages in thread
From: Jason Gunthorpe @ 2017-05-15 15:39 UTC (permalink / raw)
To: Jarkko Sakkinen; +Cc: linux-security-module, tpmdd-devel, open list
On Mon, May 15, 2017 at 02:36:02PM +0300, Jarkko Sakkinen wrote:
> On Wed, May 10, 2017 at 03:34:58PM +0300, Jarkko Sakkinen wrote:
> > On Tue, May 09, 2017 at 09:13:08AM -0600, Jason Gunthorpe wrote:
> > > On Tue, May 09, 2017 at 05:13:53PM +0300, Jarkko Sakkinen wrote:
> > > > On Sun, May 07, 2017 at 08:50:02PM +0300, Jarkko Sakkinen wrote:
> > > > > You should not do arithmetic with __be32 or __le32 types because
> > > > > sometimes it results incorrect results. Calculations must be done only
> > > > > with integers that are in in the CPU byte order. This commit migrates
> > > > > tpm_getcap() to struct tpm_buf in order to sort out these issues.
> > > > >
> > > > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > > > > Now this should work as Robertos patches move byte order conversion
> > > > > where it should be. Sadly I'm out of reach to my Dell E6400 laptop
> > > > > that I use for TPM 1.2 testing.
> > > > > drivers/char/tpm/tpm-interface.c | 30 ++++++++++++++++--------------
> > > > > drivers/char/tpm/tpm.h | 13 -------------
> > > > > 2 files changed, 16 insertions(+), 27 deletions(-)
> > > >
> > > > I've now tested this with TPM 1.2. Any complains?
> > >
> > > Seems reasonable, but which linke had the problematic arithmetic?
> > >
> > > Jason
> >
> > Arithmetic should work but it's not a good practice to do additions,
> > substractions or multiplications in any other byte order than the CPU
> > byte order.
> >
> > sparse also complains about this.
>
> Can I get your Reviewed-by for this one?
Sure, but I'm still wondering what the sparse warning was?
Jason
^ permalink raw reply [flat|nested] 20+ messages in thread
* [tpmdd-devel] [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
@ 2017-05-15 15:39 ` Jason Gunthorpe
0 siblings, 0 replies; 20+ messages in thread
From: Jason Gunthorpe @ 2017-05-15 15:39 UTC (permalink / raw)
To: linux-security-module
On Mon, May 15, 2017 at 02:36:02PM +0300, Jarkko Sakkinen wrote:
> On Wed, May 10, 2017 at 03:34:58PM +0300, Jarkko Sakkinen wrote:
> > On Tue, May 09, 2017 at 09:13:08AM -0600, Jason Gunthorpe wrote:
> > > On Tue, May 09, 2017 at 05:13:53PM +0300, Jarkko Sakkinen wrote:
> > > > On Sun, May 07, 2017 at 08:50:02PM +0300, Jarkko Sakkinen wrote:
> > > > > You should not do arithmetic with __be32 or __le32 types because
> > > > > sometimes it results incorrect results. Calculations must be done only
> > > > > with integers that are in in the CPU byte order. This commit migrates
> > > > > tpm_getcap() to struct tpm_buf in order to sort out these issues.
> > > > >
> > > > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > > > > Now this should work as Robertos patches move byte order conversion
> > > > > where it should be. Sadly I'm out of reach to my Dell E6400 laptop
> > > > > that I use for TPM 1.2 testing.
> > > > > drivers/char/tpm/tpm-interface.c | 30 ++++++++++++++++--------------
> > > > > drivers/char/tpm/tpm.h | 13 -------------
> > > > > 2 files changed, 16 insertions(+), 27 deletions(-)
> > > >
> > > > I've now tested this with TPM 1.2. Any complains?
> > >
> > > Seems reasonable, but which linke had the problematic arithmetic?
> > >
> > > Jason
> >
> > Arithmetic should work but it's not a good practice to do additions,
> > substractions or multiplications in any other byte order than the CPU
> > byte order.
> >
> > sparse also complains about this.
>
> Can I get your Reviewed-by for this one?
Sure, but I'm still wondering what the sparse warning was?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [tpmdd-devel] [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
2017-05-15 15:39 ` Jason Gunthorpe
(?)
@ 2017-05-24 16:59 ` Jarkko Sakkinen
-1 siblings, 0 replies; 20+ messages in thread
From: Jarkko Sakkinen @ 2017-05-24 16:59 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-security-module, tpmdd-devel, open list
On Mon, May 15, 2017 at 09:39:34AM -0600, Jason Gunthorpe wrote:
> On Mon, May 15, 2017 at 02:36:02PM +0300, Jarkko Sakkinen wrote:
> > On Wed, May 10, 2017 at 03:34:58PM +0300, Jarkko Sakkinen wrote:
> > > On Tue, May 09, 2017 at 09:13:08AM -0600, Jason Gunthorpe wrote:
> > > > On Tue, May 09, 2017 at 05:13:53PM +0300, Jarkko Sakkinen wrote:
> > > > > On Sun, May 07, 2017 at 08:50:02PM +0300, Jarkko Sakkinen wrote:
> > > > > > You should not do arithmetic with __be32 or __le32 types because
> > > > > > sometimes it results incorrect results. Calculations must be done only
> > > > > > with integers that are in in the CPU byte order. This commit migrates
> > > > > > tpm_getcap() to struct tpm_buf in order to sort out these issues.
> > > > > >
> > > > > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > > > > > Now this should work as Robertos patches move byte order conversion
> > > > > > where it should be. Sadly I'm out of reach to my Dell E6400 laptop
> > > > > > that I use for TPM 1.2 testing.
> > > > > > drivers/char/tpm/tpm-interface.c | 30 ++++++++++++++++--------------
> > > > > > drivers/char/tpm/tpm.h | 13 -------------
> > > > > > 2 files changed, 16 insertions(+), 27 deletions(-)
> > > > >
> > > > > I've now tested this with TPM 1.2. Any complains?
> > > >
> > > > Seems reasonable, but which linke had the problematic arithmetic?
> > > >
> > > > Jason
> > >
> > > Arithmetic should work but it's not a good practice to do additions,
> > > substractions or multiplications in any other byte order than the CPU
> > > byte order.
> > >
> > > sparse also complains about this.
> >
> > Can I get your Reviewed-by for this one?
>
> Sure, but I'm still wondering what the sparse warning was?
>
> Jason
This type of errors
drivers/char/tpm//tpm-interface.c:492:42: warning: bad assignment (-=) to restricted __be32
/Jarkko
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
@ 2017-05-24 16:59 ` Jarkko Sakkinen
0 siblings, 0 replies; 20+ messages in thread
From: Jarkko Sakkinen @ 2017-05-24 16:59 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-security-module-u79uwXL29TY76Z2rM5mHXA,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, open list
On Mon, May 15, 2017 at 09:39:34AM -0600, Jason Gunthorpe wrote:
> On Mon, May 15, 2017 at 02:36:02PM +0300, Jarkko Sakkinen wrote:
> > On Wed, May 10, 2017 at 03:34:58PM +0300, Jarkko Sakkinen wrote:
> > > On Tue, May 09, 2017 at 09:13:08AM -0600, Jason Gunthorpe wrote:
> > > > On Tue, May 09, 2017 at 05:13:53PM +0300, Jarkko Sakkinen wrote:
> > > > > On Sun, May 07, 2017 at 08:50:02PM +0300, Jarkko Sakkinen wrote:
> > > > > > You should not do arithmetic with __be32 or __le32 types because
> > > > > > sometimes it results incorrect results. Calculations must be done only
> > > > > > with integers that are in in the CPU byte order. This commit migrates
> > > > > > tpm_getcap() to struct tpm_buf in order to sort out these issues.
> > > > > >
> > > > > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > > > > > Now this should work as Robertos patches move byte order conversion
> > > > > > where it should be. Sadly I'm out of reach to my Dell E6400 laptop
> > > > > > that I use for TPM 1.2 testing.
> > > > > > drivers/char/tpm/tpm-interface.c | 30 ++++++++++++++++--------------
> > > > > > drivers/char/tpm/tpm.h | 13 -------------
> > > > > > 2 files changed, 16 insertions(+), 27 deletions(-)
> > > > >
> > > > > I've now tested this with TPM 1.2. Any complains?
> > > >
> > > > Seems reasonable, but which linke had the problematic arithmetic?
> > > >
> > > > Jason
> > >
> > > Arithmetic should work but it's not a good practice to do additions,
> > > substractions or multiplications in any other byte order than the CPU
> > > byte order.
> > >
> > > sparse also complains about this.
> >
> > Can I get your Reviewed-by for this one?
>
> Sure, but I'm still wondering what the sparse warning was?
>
> Jason
This type of errors
drivers/char/tpm//tpm-interface.c:492:42: warning: bad assignment (-=) to restricted __be32
/Jarkko
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply [flat|nested] 20+ messages in thread
* [tpmdd-devel] [PATCH] tpm: fix byte order related arithmetic inconsistency in tpm_getcap()
@ 2017-05-24 16:59 ` Jarkko Sakkinen
0 siblings, 0 replies; 20+ messages in thread
From: Jarkko Sakkinen @ 2017-05-24 16:59 UTC (permalink / raw)
To: linux-security-module
On Mon, May 15, 2017 at 09:39:34AM -0600, Jason Gunthorpe wrote:
> On Mon, May 15, 2017 at 02:36:02PM +0300, Jarkko Sakkinen wrote:
> > On Wed, May 10, 2017 at 03:34:58PM +0300, Jarkko Sakkinen wrote:
> > > On Tue, May 09, 2017 at 09:13:08AM -0600, Jason Gunthorpe wrote:
> > > > On Tue, May 09, 2017 at 05:13:53PM +0300, Jarkko Sakkinen wrote:
> > > > > On Sun, May 07, 2017 at 08:50:02PM +0300, Jarkko Sakkinen wrote:
> > > > > > You should not do arithmetic with __be32 or __le32 types because
> > > > > > sometimes it results incorrect results. Calculations must be done only
> > > > > > with integers that are in in the CPU byte order. This commit migrates
> > > > > > tpm_getcap() to struct tpm_buf in order to sort out these issues.
> > > > > >
> > > > > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > > > > > Now this should work as Robertos patches move byte order conversion
> > > > > > where it should be. Sadly I'm out of reach to my Dell E6400 laptop
> > > > > > that I use for TPM 1.2 testing.
> > > > > > drivers/char/tpm/tpm-interface.c | 30 ++++++++++++++++--------------
> > > > > > drivers/char/tpm/tpm.h | 13 -------------
> > > > > > 2 files changed, 16 insertions(+), 27 deletions(-)
> > > > >
> > > > > I've now tested this with TPM 1.2. Any complains?
> > > >
> > > > Seems reasonable, but which linke had the problematic arithmetic?
> > > >
> > > > Jason
> > >
> > > Arithmetic should work but it's not a good practice to do additions,
> > > substractions or multiplications in any other byte order than the CPU
> > > byte order.
> > >
> > > sparse also complains about this.
> >
> > Can I get your Reviewed-by for this one?
>
> Sure, but I'm still wondering what the sparse warning was?
>
> Jason
This type of errors
drivers/char/tpm//tpm-interface.c:492:42: warning: bad assignment (-=) to restricted __be32
/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 20+ messages in thread