Message ID | 20211009130828.101396-3-tianjia.zhang@linux.alibaba.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | tpm: use SM3 instead of SM3_256 | expand |
On Sat, 2021-10-09 at 21:08 +0800, Tianjia Zhang wrote: > According to https://tools.ietf.org/id/draft-oscca-cfrg-sm3-01.html, > SM3 always produces a 256-bit hash value and there are no plans for > other length development, so there is no ambiguity in the name of sm3. > > Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> This is not enough to make any changes because the commit message does not describe what goes wrong if we keep it as it was. /Jarkko
Hi Jarkko, On 10/12/21 11:21 PM, Jarkko Sakkinen wrote: > On Sat, 2021-10-09 at 21:08 +0800, Tianjia Zhang wrote: >> According to https://tools.ietf.org/id/draft-oscca-cfrg-sm3-01.html, >> SM3 always produces a 256-bit hash value and there are no plans for >> other length development, so there is no ambiguity in the name of sm3. >> >> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> > > This is not enough to make any changes because the commit message > does not describe what goes wrong if we keep it as it was. > > /Jarkko > This did not cause an error, just to use a more standard algorithm name. If it is possible to use the SM3 name instead of SM3_256 if it can be specified from the source, it is of course better. I have contacted the trustedcomputinggroup and have not yet received a reply. Best regards, Tianjia
On Thu, 2021-10-14 at 17:46 +0800, Tianjia Zhang wrote: > Hi Jarkko, > > On 10/12/21 11:21 PM, Jarkko Sakkinen wrote: > > On Sat, 2021-10-09 at 21:08 +0800, Tianjia Zhang wrote: > > > According to https://tools.ietf.org/id/draft-oscca-cfrg-sm3-01.html, > > > SM3 always produces a 256-bit hash value and there are no plans for > > > other length development, so there is no ambiguity in the name of sm3. > > > > > > Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> > > > > This is not enough to make any changes because the commit message > > does not describe what goes wrong if we keep it as it was. > > > > /Jarkko > > > > This did not cause an error, just to use a more standard algorithm name. > If it is possible to use the SM3 name instead of SM3_256 if it can be > specified from the source, it is of course better. I have contacted the > trustedcomputinggroup and have not yet received a reply. > > Best regards, > Tianjia Why don't you then create a patch set that fully removes SM3_256, if it is incorrect? This looks a bit half-baked patch set. /Jarkko
Hi Jarkko, On 10/15/21 11:19 PM, Jarkko Sakkinen wrote: > On Thu, 2021-10-14 at 17:46 +0800, Tianjia Zhang wrote: >> Hi Jarkko, >> >> On 10/12/21 11:21 PM, Jarkko Sakkinen wrote: >>> On Sat, 2021-10-09 at 21:08 +0800, Tianjia Zhang wrote: >>>> According to https://tools.ietf.org/id/draft-oscca-cfrg-sm3-01.html, >>>> SM3 always produces a 256-bit hash value and there are no plans for >>>> other length development, so there is no ambiguity in the name of sm3. >>>> >>>> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> >>> >>> This is not enough to make any changes because the commit message >>> does not describe what goes wrong if we keep it as it was. >>> >>> /Jarkko >>> >> >> This did not cause an error, just to use a more standard algorithm name. >> If it is possible to use the SM3 name instead of SM3_256 if it can be >> specified from the source, it is of course better. I have contacted the >> trustedcomputinggroup and have not yet received a reply. >> >> Best regards, >> Tianjia > > Why don't you then create a patch set that fully removes SM3_256, if it > is incorrect? > > This looks a bit half-baked patch set. > > /Jarkko > This series of patch is a complete replacement. Patch 1 is a replacement of the crypto subsystem, and patch 2 is a replacement of the tpm driver. Best regards, Tianjia
On Mon, 2021-10-18 at 10:37 +0800, Tianjia Zhang wrote: > Hi Jarkko, > > On 10/15/21 11:19 PM, Jarkko Sakkinen wrote: > > On Thu, 2021-10-14 at 17:46 +0800, Tianjia Zhang wrote: > > > Hi Jarkko, > > > > > > On 10/12/21 11:21 PM, Jarkko Sakkinen wrote: > > > > On Sat, 2021-10-09 at 21:08 +0800, Tianjia Zhang wrote: > > > > > According to https://tools.ietf.org/id/draft-oscca-cfrg-sm3-01.html, > > > > > SM3 always produces a 256-bit hash value and there are no plans for > > > > > other length development, so there is no ambiguity in the name of sm3. > > > > > > > > > > Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> > > > > > > > > This is not enough to make any changes because the commit message > > > > does not describe what goes wrong if we keep it as it was. > > > > > > > > /Jarkko > > > > > > > > > > This did not cause an error, just to use a more standard algorithm name. > > > If it is possible to use the SM3 name instead of SM3_256 if it can be > > > specified from the source, it is of course better. I have contacted the > > > trustedcomputinggroup and have not yet received a reply. > > > > > > Best regards, > > > Tianjia > > > > Why don't you then create a patch set that fully removes SM3_256, if it > > is incorrect? > > > > This looks a bit half-baked patch set. > > > > /Jarkko > > > > This series of patch is a complete replacement. Patch 1 is a replacement > of the crypto subsystem, and patch 2 is a replacement of the tpm driver. > > Best regards, > Tianjia In which patch that symbol is removed? /Jarkko
diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c index 63f03cfb8e6a..fe6c785dc84a 100644 --- a/drivers/char/tpm/tpm-sysfs.c +++ b/drivers/char/tpm/tpm-sysfs.c @@ -471,7 +471,7 @@ PCR_ATTR_BUILD(TPM_ALG_SHA1, sha1); PCR_ATTR_BUILD(TPM_ALG_SHA256, sha256); PCR_ATTR_BUILD(TPM_ALG_SHA384, sha384); PCR_ATTR_BUILD(TPM_ALG_SHA512, sha512); -PCR_ATTR_BUILD(TPM_ALG_SM3_256, sm3); +PCR_ATTR_BUILD(TPM_ALG_SM3, sm3); void tpm_sysfs_add_device(struct tpm_chip *chip) @@ -500,7 +500,7 @@ void tpm_sysfs_add_device(struct tpm_chip *chip) case TPM_ALG_SHA512: chip->groups[chip->groups_cnt++] = &pcr_group_sha512; break; - case TPM_ALG_SM3_256: + case TPM_ALG_SM3: chip->groups[chip->groups_cnt++] = &pcr_group_sm3; break; default: diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c index 20f55de9d87b..d5a9410d2273 100644 --- a/drivers/char/tpm/tpm2-cmd.c +++ b/drivers/char/tpm/tpm2-cmd.c @@ -19,7 +19,7 @@ static struct tpm2_hash tpm2_hash_map[] = { {HASH_ALGO_SHA256, TPM_ALG_SHA256}, {HASH_ALGO_SHA384, TPM_ALG_SHA384}, {HASH_ALGO_SHA512, TPM_ALG_SHA512}, - {HASH_ALGO_SM3, TPM_ALG_SM3_256}, + {HASH_ALGO_SM3, TPM_ALG_SM3}, }; int tpm2_get_timeouts(struct tpm_chip *chip) diff --git a/include/linux/tpm.h b/include/linux/tpm.h index aa11fe323c56..56a79fee1250 100644 --- a/include/linux/tpm.h +++ b/include/linux/tpm.h @@ -40,7 +40,7 @@ enum tpm_algorithms { TPM_ALG_SHA384 = 0x000C, TPM_ALG_SHA512 = 0x000D, TPM_ALG_NULL = 0x0010, - TPM_ALG_SM3_256 = 0x0012, + TPM_ALG_SM3 = 0x0012, }; /* diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c index 52a696035176..b15a9961213d 100644 --- a/security/keys/trusted-keys/trusted_tpm2.c +++ b/security/keys/trusted-keys/trusted_tpm2.c @@ -23,7 +23,7 @@ static struct tpm2_hash tpm2_hash_map[] = { {HASH_ALGO_SHA256, TPM_ALG_SHA256}, {HASH_ALGO_SHA384, TPM_ALG_SHA384}, {HASH_ALGO_SHA512, TPM_ALG_SHA512}, - {HASH_ALGO_SM3, TPM_ALG_SM3_256}, + {HASH_ALGO_SM3, TPM_ALG_SM3}, }; static u32 tpm2key_oid[] = { 2, 23, 133, 10, 1, 5 };
According to https://tools.ietf.org/id/draft-oscca-cfrg-sm3-01.html, SM3 always produces a 256-bit hash value and there are no plans for other length development, so there is no ambiguity in the name of sm3. Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> --- drivers/char/tpm/tpm-sysfs.c | 4 ++-- drivers/char/tpm/tpm2-cmd.c | 2 +- include/linux/tpm.h | 2 +- security/keys/trusted-keys/trusted_tpm2.c | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-)