Re: [PATCH] ecc: delete a useless function declaration
在 2021/4/2 18:34, Christophe Leroy 写道: Le 02/04/2021 à 11:55, Meng Yu a écrit : This function declaration has been added in 'ecc_curve.h', delete it in 'crypto/ecc.h'. Fixes: 14bb76768275(crypto: ecc - expose ecc curves) Fixes tag is wrong I think, should be 4e6602916bc6 Yes, you are right, thank you. Signed-off-by: Meng Yu --- crypto/ecc.h | 8 1 file changed, 8 deletions(-) diff --git a/crypto/ecc.h b/crypto/ecc.h index 46aa9bc..a006132 100644 --- a/crypto/ecc.h +++ b/crypto/ecc.h @@ -56,14 +56,6 @@ static inline void ecc_swap_digits(const u64 *in, u64 *out, unsigned int ndigits } /** - * ecc_get_curve() - Get a curve given its curve_id - * @curve_id: Id of the curve - * - * Returns pointer to the curve data, NULL if curve is not available - */ -const struct ecc_curve *ecc_get_curve(unsigned int curve_id); - -/** * ecc_is_key_valid() - Validate a given ECDH private key * * @curve_id: id representing the curve to use .
Re: [PATCH] crypto: hisilicon/hpre - rsa key should not be empty
在 2021/4/2 18:22, Herbert Xu 写道: On Fri, Apr 02, 2021 at 06:16:16PM +0800, yumeng wrote: I think it is not a real bug, and soft fallback setkey can always catch the error. But our original intention was to make it don't go to 'xxx_set_pub_key' when the key is null, and it can return an error earlier. But maybe it is not good. It might make sense to check them twice if you were touching them directly, e.g., poking inside the key. However, it appears that your driver simply palms off the key to rsa_helper.c which should check the key/keylen too so I think there is no need for this patch for now. Thanks, OK, thank you.
Re: [PATCH] crypto: hisilicon/hpre - rsa key should not be empty
在 2021/4/2 15:12, Herbert Xu 写道: On Fri, Mar 26, 2021 at 02:13:32PM +0800, Meng Yu wrote: We should ensure key is not empty before we set key. Signed-off-by: Meng Yu --- drivers/crypto/hisilicon/hpre/hpre_crypto.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c b/drivers/crypto/hisilicon/hpre/hpre_crypto.c index 53068d2..7cf7d80 100644 --- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c +++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c @@ -1093,6 +1093,9 @@ static int hpre_rsa_setpubkey(struct crypto_akcipher *tfm, const void *key, struct hpre_ctx *ctx = akcipher_tfm_ctx(tfm); int ret; + if (!key || !keylen) + return -EINVAL; + ret = crypto_akcipher_set_pub_key(ctx->rsa.soft_tfm, key, keylen); Does this fix a real bug? Wouldn't the soft fallback setkey catch this anyhow? I think it is not a real bug, and soft fallback setkey can always catch the error. But our original intention was to make it don't go to 'xxx_set_pub_key' when the key is null, and it can return an error earlier. But maybe it is not good.
Re: [PATCH -next] drivers: crypto: CRYPTO_DEV_HISI_HPRE select CRYPTO_ECC and CRYPTO_ECDH
Thanks, there is a similar patch to yours that was sent in advance: https://www.spinics.net/lists/linux-crypto/msg54238.html 在 2021/3/26 15:16, Zhang Jianhua 写道: If CRYPTO_DEV_HISI_HPRE=y, the following errors will be seen while building hpre_crypto.c drivers/crypto/hisilicon/hpre/hpre_crypto.o: In function `hpre_curve25519_compute_value': hpre_crypto.c:(.text+0x151b): undefined reference to `ecc_get_curve25519' drivers/crypto/hisilicon/hpre/hpre_crypto.o: In function `hpre_curve25519_set_secret': hpre_crypto.c:(.text+0x2714): undefined reference to `ecc_get_curve25519' drivers/crypto/hisilicon/hpre/hpre_crypto.o: In function `hpre_ecdh_set_secret': hpre_crypto.c:(.text+0x27ed): undefined reference to `crypto_ecdh_decode_key' hpre_crypto.c:(.text+0x2954): undefined reference to `ecc_get_curve' Reported-by: Hulk Robot Signed-off-by: Zhang Jianhua --- drivers/crypto/hisilicon/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/crypto/hisilicon/Kconfig b/drivers/crypto/hisilicon/Kconfig index c45adb15ce8d..d87c89af2a7f 100644 --- a/drivers/crypto/hisilicon/Kconfig +++ b/drivers/crypto/hisilicon/Kconfig @@ -69,6 +69,8 @@ config CRYPTO_DEV_HISI_HPRE select CRYPTO_DEV_HISI_QM select CRYPTO_DH select CRYPTO_RSA + select CRYPTO_ECC + select CRYPTO_ECDH help Support for HiSilicon HPRE(High Performance RSA Engine) accelerator, which can accelerate RSA and DH algorithms.
[PATCH v9 9/9] certs: Add support for using elliptic curve keys for signing modules
在 2021/3/1 21:11, Mimi Zohar 写道: On Sat, 2021-02-27 at 11:35 +0800, yumeng wrote: 在 2021/2/26 0:08, Stefan Berger 写道: From: Stefan Berger diff --git a/certs/Makefile b/certs/Makefile index 3fe6b73786fa..c487d7021c54 100644 --- a/certs/Makefile +++ b/certs/Makefile @@ -69,6 +69,18 @@ else SIGNER = -signkey $(obj)/signing_key.key endif # CONFIG_IMA_APPRAISE_MODSIG Is there anything wrong in this patch? I can't apply it when I use 'git am '. errors like below: error: certs/Kconfig: does not match index error: patch failed: certs/Makefile:69 error: certs/Makefile: patch does not apply Thanks Nothing wrong with the patch, just a dependency. From the Change log: - This patch builds on top Nayna's series for 'kernel build support for loading the kernel module signing key'. - https://lkml.org/lkml/2021/2/18/856 thanks, Mimi OK, thank you. Sorry for the noise.
Re: [PATCH v9 9/9] certs: Add support for using elliptic curve keys for signing modules
在 2021/2/26 0:08, Stefan Berger 写道: From: Stefan Berger diff --git a/certs/Makefile b/certs/Makefile index 3fe6b73786fa..c487d7021c54 100644 --- a/certs/Makefile +++ b/certs/Makefile @@ -69,6 +69,18 @@ else SIGNER = -signkey $(obj)/signing_key.key endif # CONFIG_IMA_APPRAISE_MODSIG Is there anything wrong in this patch? I can't apply it when I use 'git am '. errors like below: error: certs/Kconfig: does not match index error: patch failed: certs/Makefile:69 error: certs/Makefile: patch does not apply Thanks
Re: [PATCH v9 3/7] crypto: move curve_id of ECDH from the key to algorithm name
在 2021/2/24 18:15, tudor.amba...@microchip.com 写道:
On 2/24/21 3:29 AM, yumeng wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
在 2021/2/23 18:44, tudor.amba...@microchip.com 写道:
Hi,
On 2/23/21 9:10 AM, Meng Yu wrote:
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -104,7 +104,7 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm,
const void *buf,
return -EINVAL;
}
- ctx->n_sz = atmel_ecdh_supported_curve(params.curve_id);
+ ctx->n_sz = atmel_ecdh_supported_curve(ctx->curve_id);
if (!ctx->n_sz || params.key_size) {
/* fallback to ecdh software implementation */
ctx->do_fallback = true;
Now that you moved the curve id info into the alg name, and it is
no longer dynamically discovered when decoding the key, does it
still make sense to keep the curve id, the key size checks, and
the fallback to the software implementation?
I think we can keep the curve id, the key size check if 'atmel-ecc' may
support other curves in the future, and if you're sure P256 is the only
curve 'atmel-ecc' uses, and it will be changed, we can delete it.
And fallback to ecdh software implementation is needed when
params.key_size is zero.
I've read the code again, now I remember. The fallback is needed indeed,
but for other reason. ecdh-nist-p256 will be handled in the crypto IP
only when its user provides a zero length private key: we will use a
pre-provisioned private key that can't be read outside of the device.
The fallback was needed for ecdh-nist-p256 when the user provides a
non-zero private key, or for other curve IDs.
Since the atecc508 and atecc608 (for which there isn't support in kernel
as of now) both support just NIST Standard P256 Elliptic Curve, and the
curve id is now unique per alg, the ctx->curve_id handling does no longer
make sense. So please remove the ctx->curve_id handling. ctx->n_sz can be
removed too and use instead directly ATMEL_ECC_NIST_P256_N_SIZE, similar
to how ATMEL_ECC_PUBKEY_SIZE is used.
OK, thanks, I will remove it. But I'd like to wait 2 more days, as maybe
the owners of other modules (like crypto or bluetooth) have any comments.
thanks.
Re: [PATCH v9 3/7] crypto: move curve_id of ECDH from the key to algorithm name
在 2021/2/23 18:44, tudor.amba...@microchip.com 写道:
Hi,
On 2/23/21 9:10 AM, Meng Yu wrote:
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -104,7 +104,7 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm,
const void *buf,
return -EINVAL;
}
- ctx->n_sz = atmel_ecdh_supported_curve(params.curve_id);
+ ctx->n_sz = atmel_ecdh_supported_curve(ctx->curve_id);
if (!ctx->n_sz || params.key_size) {
/* fallback to ecdh software implementation */
ctx->do_fallback = true;
Now that you moved the curve id info into the alg name, and it is
no longer dynamically discovered when decoding the key, does it
still make sense to keep the curve id, the key size checks, and
the fallback to the software implementation?
I think we can keep the curve id, the key size check if 'atmel-ecc' may
support other curves in the future, and if you're sure P256 is the only
curve 'atmel-ecc' uses, and it will be changed, we can delete it.
And fallback to ecdh software implementation is needed when
params.key_size is zero.
I don't have an atecc508 at hand to test the changes, but I expect
your changes won't affect the functionality.
OK, if you or your team members have an atecc508, please help test.
Re: [PATCH v9 3/7] crypto: move curve_id of ECDH from the key to algorithm name
在 2021/2/23 18:44, tudor.amba...@microchip.com 写道:
Hi,
On 2/23/21 9:10 AM, Meng Yu wrote:
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -104,7 +104,7 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm,
const void *buf,
return -EINVAL;
}
- ctx->n_sz = atmel_ecdh_supported_curve(params.curve_id);
+ ctx->n_sz = atmel_ecdh_supported_curve(ctx->curve_id);
if (!ctx->n_sz || params.key_size) {
/* fallback to ecdh software implementation */
ctx->do_fallback = true;
Now that you moved the curve id info into the alg name, and it is
no longer dynamically discovered when decoding the key, does it
still make sense to keep the curve id, the key size checks, and
the fallback to the software implementation?
Yes, I think we can keep this code if 'atmel-ecc' may support
new other curves at future, and if you're sure P256 is the only curve
'atmel-ecc' uses, and it will never be changed, we can delete it.
I don't have an atecc508 at hand to test the changes, but I expect
your changes won't affect the functionality.
OK, when you or your team members have an atecc508, please help test.
Re: [PATCH v8 7/9] crypto: hisilicon/hpre - add 'ECDH' algorithm
在 2021/2/19 4:01, Herbert Xu 写道: On Thu, Feb 18, 2021 at 10:24:40AM +0800, yumeng wrote: Ecdh-nist-p384 is supported by HPRE now, currently there is no patch of the generic ecdh-nist-p384. In that case please leave it out until there is: 1) An in-kernel user of p384. 2) There is a generic implementation. Thanks, OK, I will, thanks. And p224 and p521 are the same as p384 (has no user and no generic implementation), so they should be supported by HPRE later, is it? thanks.
Re: [PATCH v8 7/9] crypto: hisilicon/hpre - add 'ECDH' algorithm
在 2021/2/10 12:57, Herbert Xu 写道: On Mon, Feb 08, 2021 at 05:38:55PM +0800, Meng Yu wrote: 1. Enable 'ECDH' algorithm in Kunpeng 930; 2. HPRE ECDH Support: ecdh-nist-p192, ecdh-nist-p224, ecdh-nist-p256, ecdh-nist-p384, ecdh-nist-p521. Where is the patch that adds the generic ecdh-nist-p384? Thanks, Ecdh-nist-p384 is supported by HPRE now, currently there is no patch of the generic ecdh-nist-p384.
Re: [PATCH v8 3/9] crypto: atmel-ecc - move curve_id of ECDH from the key to algorithm name
在 2021/2/10 12:56, Herbert Xu 写道: On Mon, Feb 08, 2021 at 05:38:51PM +0800, Meng Yu wrote: As curve id of ECDH will be moved from its key into algorithm name, we cannot use 'curve_id' in 'struct ecdh', so we should modify ECDH driver in atmel, and make ECDH algorithm name be the same as crypto (like 'ecdh-nist-pxxx'); Signed-off-by: Meng Yu Reviewed-by: Zaibo Xu --- drivers/crypto/atmel-ecc.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) Patches 3-5 need to be squashed into one in order to avoid future bisection failures. The alternative is to let the new/old names coexist but it's probably not worth it for this case as the number of drivers impacted is small. Thanks, OK, thanks.
Re: [PATCH v6 1/4] crypto: Add support for ECDSA signature verification
在 2021/2/1 7:32, Stefan Berger 写道: +/** + * ecc_get_curve() - Get a curve given its curve_id + * + * @curve_id: Id of the curve + * + * Returns pointer to the curve data, NULL if curve is not available + */ +const struct ecc_curve *ecc_get_curve(unsigned int curve_id); + /** * ecc_is_key_valid() - Validate a given ECDH private key Shall we move this definition to 'include/crypto'? Other drivers may also want to use it.
Re: [PATCH v7 4/7] crypto: add ecc curve and expose them
在 2021/1/28 13:03, Herbert Xu 写道: On Fri, Jan 22, 2021 at 03:09:52PM +0800, Meng Yu wrote: 1. Add ecc curves(P224, P384, P521) for ECDH; OK I think this is getting unwieldy. In light of the fact that we already have hardware that supports a specific subset of curves, I think perhaps it would be better to move the curve ID from the key into the algorithm name instead. IOW, instead of allocating ecdh, you would allocate ecdh-nist-pXXX. Any comments? Thanks, Yes，It is a good idea, thank you!
Re: [PATCH v5 3/5] crypto: expose elliptic curve parameters as Crypto APIs
在 2021/1/3 5:29, Herbert Xu 写道: On Thu, Dec 24, 2020 at 02:08:25PM +0800, Meng Yu wrote: Move elliptic curves definition to 'include/crypto/ecc_curve_defs.h', so all can use it, Signed-off-by: Meng Yu Reviewed-by: Zaibo Xu --- crypto/ecc.c| 1 - crypto/ecc.h| 37 + crypto/ecc_curve_defs.h | 57 - crypto/ecrdsa_defs.h| 2 +- include/crypto/ecc_curve_defs.h | 92 + 5 files changed, 95 insertions(+), 94 deletions(-) delete mode 100644 crypto/ecc_curve_defs.h create mode 100644 include/crypto/ecc_curve_defs.h This conflicts with https://patchwork.kernel.org/project/linux-crypto/patch/20201217172101.381772-3-daniele.alessandre...@linux.intel.com/ Please discuss with each other on how you would like to proceed. Thanks, hello, Daniele, In my patch, I move elliptic curves definition to 'include/crypto/ecc_curve_defs.h', which include the P-384 curve you need, and you can easily import it to your driver. And if you include 'crypto/ecc_curve_defs.h', 'drivers/crypto/keembay/ocs-ecc-curve-defs.h' is not needed. Could you think about it, to rely on my patchset?
Re: [PATCH v4 4/5] crypto: hisilicon/hpre - add 'ECDH' algorithm
在 2020/12/17 4:10, Stephan Mueller 写道: Am Mittwoch, dem 16.12.2020 um 10:39 +0800 schrieb yumeng: Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu: +/* size in bytes of the n prime */ +#define HPRE_ECC_NIST_P128_N_SIZE 16 Do we truly need P-128? Besides, I do not see that curve being defined in contemporary cipher specs. +#define HPRE_ECC_NIST_P192_N_SIZE 24 +#define HPRE_ECC_NIST_P224_N_SIZE 28 +#define HPRE_ECC_NIST_P256_N_SIZE 32 +#define HPRE_ECC_NIST_P320_N_SIZE 40 Do we truly need P-320? Besides, I do not see that curve being defined in contemporary cipher specs. Yes, in rfc 5903, only P-256, P-384 and P-521 is defined, but in 'rfc5639' and "SEC 2: Recommended Elliptic Curve Domain Parameters", other curves like P-128, P-192, P-224, and P-320 curve parameters are found, and they are used in 'openssl'; How about your idea? Who is going to use that curve considering that common protocols that are implemented in the kernel do not use it? Thanks Stephan I see in "SEC 2: Recommended Elliptic Curve Domain ParametersVersion2.0" that 'Recommend Elliptic Curve Domain Parameters over Fp' are secp192, secp224, secp256, secp384, and secp521, secp128 and secp320 are not recommended. So you mean it's better not to include secp128 and secp320, right? Thanks,
Re: [PATCH v4 5/5] crypto: hisilicon/hpre - add 'CURVE25519' algorithm
Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu:
+/* curve25519 */
+static u64 curve25519_g_x[] = { 0x0009, 0x,
+ 0x, 0x };
+static u64 curve25519_p[] = { 0xffed, 0x,
+ 0x, 0x7fff };
+static u64 curve25519_a[] = { 0x0001DB41, 0x,
+ 0x, 0x };
+static const struct ecc_curve ecc_25519 = {
+ .name = "curve25519",
+ .g = {
+ .x = curve25519_g_x,
+ .ndigits = 4,
+ },
+ .p = curve25519_p,
+ .a = curve25519_a,
+};
With this definition, I am not sure whether ecc_is_pubkey_valid_partial would
work correctly. At least it *seems* that there would be a NULL-pointer
dereference in vli_add with the undefined .b value. Did you test and can you
confirm?
Thanks
Stephan
'static const struct ecc_curve ecc_25519' is curve25519's parameters,
only used in 'curve25519', not used by 'ECDH';
Thanks,
Re: [PATCH v4 4/5] crypto: hisilicon/hpre - add 'ECDH' algorithm
Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu: +/* size in bytes of the n prime */ +#define HPRE_ECC_NIST_P128_N_SIZE 16 Do we truly need P-128? Besides, I do not see that curve being defined in contemporary cipher specs. +#define HPRE_ECC_NIST_P192_N_SIZE 24 +#define HPRE_ECC_NIST_P224_N_SIZE 28 +#define HPRE_ECC_NIST_P256_N_SIZE 32 +#define HPRE_ECC_NIST_P320_N_SIZE 40 Do we truly need P-320? Besides, I do not see that curve being defined in contemporary cipher specs. Yes, in rfc 5903, only P-256, P-384 and P-521 is defined, but in 'rfc5639' and "SEC 2: Recommended Elliptic Curve Domain Parameters", other curves like P-128, P-192, P-224, and P-320 curve parameters are found, and they are used in 'openssl'; How about your idea? Thanks, +#define HPRE_ECC_NIST_P384_N_SIZE 48 +#define HPRE_ECC_NIST_P521_N_SIZE 66 + +/* size in bytes */ +#define HPRE_ECC_HW256_KSZ_B 32 +#define HPRE_ECC_HW384_KSZ_B 48 +#define HPRE_ECC_HW576_KSZ_B 72 + +#define HPRE_ECDH_MAX_SZ HPRE_ECC_HW576_KSZ_B] Ciao Stephan .
Re: Fwd: Re: [PATCH v4 3/5] crypto: expose elliptic curve parameters as Crypto APIs
Meng,
It looks like not just definitions but some static data is moved to
includes. Why?
Thanks,
Yes, as both 'crypto' and HPRE use elliptic curves parameters, once
we keep them in 'include/crypto/ecc_curve_defs.h', crypto drivers
can use curves parameters without redefining them.
Thanks,
On Fri, Dec 11, 2020 at 02:30:32PM +0800, Meng Yu wrote:
Move elliptic curves definition to 'include/crypto/ecc_curve_defs.h',
so all can use it,
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
crypto/ecc.c| 1 -
crypto/ecc.h| 37 +
crypto/ecc_curve_defs.h | 57 -
crypto/ecrdsa_defs.h| 2 +-
include/crypto/ecc_curve_defs.h | 92 +
5 files changed, 95 insertions(+), 94 deletions(-)
delete mode 100644 crypto/ecc_curve_defs.h
create mode 100644 include/crypto/ecc_curve_defs.h
diff --git a/crypto/ecc.c b/crypto/ecc.c
index c80aa25..f23efdd 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -35,7 +35,6 @@
#include
#include "ecc.h"
-#include "ecc_curve_defs.h"
typedef struct {
u64 m_low;
diff --git a/crypto/ecc.h b/crypto/ecc.h
index d4e546b..e5afaf3 100644
--- a/crypto/ecc.h
+++ b/crypto/ecc.h
@@ -26,6 +26,8 @@
#ifndef _CRYPTO_ECC_H
#define _CRYPTO_ECC_H
+#include
+
/* One digit is u64 qword. */
#define ECC_CURVE_NIST_P192_DIGITS 3
#define ECC_CURVE_NIST_P256_DIGITS 4
@@ -33,44 +35,9 @@
#define ECC_DIGITS_TO_BYTES_SHIFT 3
-/**
- * struct ecc_point - elliptic curve point in affine coordinates
- *
- * @x: X coordinate in vli form.
- * @y: Y coordinate in vli form.
- * @ndigits: Length of vlis in u64 qwords.
- */
-struct ecc_point {
- u64 *x;
- u64 *y;
- u8 ndigits;
-};
-
#define ECC_POINT_INIT(x, y, ndigits) (struct ecc_point) { x, y, ndigits }
/**
- * struct ecc_curve - definition of elliptic curve
- *
- * @name: Short name of the curve.
- * @g: Generator point of the curve.
- * @p: Prime number, if Barrett's reduction is used for this curve
- * pre-calculated value 'mu' is appended to the @p after ndigits.
- * Use of Barrett's reduction is heuristically determined in
- * vli_mmod_fast().
- * @n: Order of the curve group.
- * @a: Curve parameter a.
- * @b: Curve parameter b.
- */
-struct ecc_curve {
- char *name;
- struct ecc_point g;
- u64 *p;
- u64 *n;
- u64 *a;
- u64 *b;
-};
-
-/**
* ecc_is_key_valid() - Validate a given ECDH private key
*
* @curve_id: id representing the curve to use
diff --git a/crypto/ecc_curve_defs.h b/crypto/ecc_curve_defs.h
deleted file mode 100644
index 69be6c7..000
--- a/crypto/ecc_curve_defs.h
+++ /dev/null
@@ -1,57 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _CRYTO_ECC_CURVE_DEFS_H
-#define _CRYTO_ECC_CURVE_DEFS_H
-
-/* NIST P-192: a = p - 3 */
-static u64 nist_p192_g_x[] = { 0xF4FF0AFD82FF1012ull, 0x7CBF20EB43A18800ull,
- 0x188DA80EB03090F6ull };
-static u64 nist_p192_g_y[] = { 0x73F977A11E794811ull, 0x631011ED6B24CDD5ull,
- 0x07192B95FFC8DA78ull };
-static u64 nist_p192_p[] = { 0xull, 0xFFFEull,
- 0xull };
-static u64 nist_p192_n[] = { 0x146BC9B1B4D22831ull, 0x99DEF836ull,
- 0xull };
-static u64 nist_p192_a[] = { 0xFFFCull, 0xFFFEull,
- 0xull };
-static u64 nist_p192_b[] = { 0xFEB8DEECC146B9B1ull, 0x0FA7E9AB72243049ull,
- 0x64210519E59C80E7ull };
-static struct ecc_curve nist_p192 = {
- .name = "nist_192",
- .g = {
- .x = nist_p192_g_x,
- .y = nist_p192_g_y,
- .ndigits = 3,
- },
- .p = nist_p192_p,
- .n = nist_p192_n,
- .a = nist_p192_a,
- .b = nist_p192_b
-};
-
-/* NIST P-256: a = p - 3 */
-static u64 nist_p256_g_x[] = { 0xF4A13945D898C296ull, 0x77037D812DEB33A0ull,
- 0xF8BCE6E563A440F2ull, 0x6B17D1F2E12C4247ull };
-static u64 nist_p256_g_y[] = { 0xCBB6406837BF51F5ull, 0x2BCE33576B315ECEull,
- 0x8EE7EB4A7C0F9E16ull, 0x4FE342E2FE1A7F9Bull };
-static u64 nist_p256_p[] = { 0xull, 0xull,
- 0xull, 0x0001ull };
-static u64 nist_p256_n[] = { 0xF3B9CAC2FC632551ull, 0xBCE6FAADA7179E84ull,
- 0xull, 0xull };
-static u64 nist_p256_a[] = { 0xFFFCull, 0xull,
- 0xull, 0x0001ull };
-static u64 nist_p256_b[] = { 0x3BCE3C3E27D2604Bull, 0x651D06B0CC53B0F6ull,
-
答复: [PATCH v3 4/5] crypto: hisilicon/hpre - add 'ECDH' algorithm
Ok, I think I can make a patch to keep them at "include/crypto" .
-邮件原件-
发件人: Stephan Mueller [mailto:smuel...@chronox.de]
发送时间: 2020年11月19日 4:25
收件人: yumeng (J) ; herb...@gondor.apana.org.au;
da...@davemloft.net
抄送: linux-cry...@vger.kernel.org; Xu Zaibo ; Wangzhou (B)
; linux-kernel@vger.kernel.org
主题: Re: [PATCH v3 4/5] crypto: hisilicon/hpre - add 'ECDH' algorithm
Am Mittwoch, den 18.11.2020, 11:47 +0800 schrieb Meng Yu:
Hi Meng,
> Enable 'ECDH' algorithm in Kunpeng 930.
>
> Signed-off-by: Meng Yu
> Reviewed-by: Zaibo Xu
> ---
> drivers/crypto/hisilicon/hpre/hpre.h | 2 +-
> drivers/crypto/hisilicon/hpre/hpre_crypto.c | 802
> +++-
> drivers/crypto/hisilicon/hpre/hpre_main.c | 1 +
> 3 files changed, 800 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/crypto/hisilicon/hpre/hpre.h
> b/drivers/crypto/hisilicon/hpre/hpre.h
> index 02193e1..50e6b2e 100644
> --- a/drivers/crypto/hisilicon/hpre/hpre.h
> +++ b/drivers/crypto/hisilicon/hpre/hpre.h
> @@ -83,6 +83,7 @@ enum hpre_alg_type {
> HPRE_ALG_KG_CRT = 0x3,
> HPRE_ALG_DH_G2 = 0x4,
> HPRE_ALG_DH = 0x5,
> + HPRE_ALG_ECC_MUL = 0xD,
> };
>
> struct hpre_sqe {
> @@ -104,5 +105,4 @@ struct hisi_qp *hpre_create_qp(u8 type);
> int hpre_algs_register(struct hisi_qm *qm);
> void hpre_algs_unregister(struct hisi_qm *qm);
>
> -
> #endif
> diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> index 712bea9..b7814ce 100644
> --- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> +++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> @@ -2,6 +2,7 @@
> /* Copyright (c) 2019 HiSilicon Limited. */
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -36,6 +37,342 @@ struct hpre_ctx;
> #define HPRE_DFX_SEC_TO_US 100
> #define HPRE_DFX_US_TO_NS 1000
>
> +/* HPRE support 7 curves (include curve P192 and P256 in ecdh.h) */
> +#define HPRE_ECC_CURVE_NIST_P128 0X0003 #define
> +HPRE_ECC_CURVE_NIST_P320 0X0004 #define
> +HPRE_ECC_CURVE_NIST_P384 0X0005 #define
> +HPRE_ECC_CURVE_NIST_P521 0X0006 #define
> +HPRE_ECC_CURVE_NIST_P224 0X0007
> +
> +/* size in bytes of the n prime */
> +#define HPRE_ECC_NIST_P128_N_SIZE 16 #define
> +HPRE_ECC_NIST_P192_N_SIZE 24 #define HPRE_ECC_NIST_P224_N_SIZE
> +28 #define HPRE_ECC_NIST_P256_N_SIZE 32 #define
> +HPRE_ECC_NIST_P320_N_SIZE 40 #define HPRE_ECC_NIST_P384_N_SIZE
> +48 #define HPRE_ECC_NIST_P521_N_SIZE 66
> +
> +/* size in bytes */
> +#define HPRE_ECC_HW256_KSZ_B 32
> +#define HPRE_ECC_HW384_KSZ_B 48
> +#define HPRE_ECC_HW576_KSZ_B 72
> +
> +#define HPRE_ECDH_MAX_SZ HPRE_ECC_HW576_KSZ_B
> +
> +struct curve_param_desc {
> + __u32 id;
> + const unsigned char *p;
> + const unsigned char *a;
> + const unsigned char *b;
> + const unsigned char *gx;
> + const unsigned char *gy;
> + const unsigned char *n;
> +};
> +
> +/* ECC CURVE PARAMS */
> +/* 128 bits */
> +static const unsigned char ecdh_p128_p[] = {
> + 0xFF, 0xFF, 0xFF, 0xFD, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
> +0xFF,
> 0xFF,
> + 0xFF, 0xFF, 0xFF, 0xFF
> +};
> +static const unsigned char ecdh_p128_a[] = {
> + 0xFF, 0xFF, 0xFF, 0xFD, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
> +0xFF,
> 0xFF,
> + 0xFF, 0xFF, 0xFF, 0xFC
> +};
> +static const unsigned char ecdh_p128_b[] = {
> + 0xE8, 0x75, 0x79, 0xC1, 0x10, 0x79, 0xF4, 0x3D, 0xD8, 0x24,
> +0x99,
> 0x3C,
> + 0x2C, 0xEE, 0x5E, 0xD3
> +};
> +static const unsigned char ecdh_p128_x[] = {
> + 0x16, 0x1F, 0xF7, 0x52, 0x8B, 0x89, 0x9B, 0x2D, 0x0C, 0x28,
> +0x60,
> 0x7C,
> + 0xA5, 0x2C, 0x5B, 0x86
> +};
> +static const unsigned char ecdh_p128_y[] = {
> + 0xcf, 0x5a, 0xc8, 0x39, 0x5b, 0xaf, 0xeb, 0x13, 0xc0, 0x2d,
> +0xa2,
> 0x92,
> + 0xdd, 0xed, 0x7a, 0x83
> +};
> +static const unsigned char ecdh_p128_n[] = {
> + 0xFF, 0xFF, 0xFF, 0xFE, 0x00, 0x00, 0x00, 0x00, 0x75, 0xA3,
> +0x0D,
> 0x1B,
> + 0x90, 0x38, 0xA1, 0x15
> +};
> +
> +/* 192 bits */
> +static const unsigned char ecdh_p192_p[] = {
> + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
> +0xFF,
> 0xFF,
> + 0xFF, 0xFF, 0xFF, 0xFE, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
> +0xFF,
> 0xFF
> +};
> +static const unsigned char ecdh_p192_a[] = {
> + 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
> +0xFF,
> 0xFF,
> + 0xFF, 0xFF, 0xFF, 0xFE, 0xFF, 0xFF, 0xFF, 0
[PATCH v2 0/3] crypto: hisilicon/hpre - misc clean up and fixes
Adjust some tiny coding problems and fix a bug of DH algorithm. Changes since v1: Remove 'u64' cast in 'cpu_to_le64'; Meng Yu (3): crypto: hisilicon/hpre - remove useless code crypto: hisilicon/hpre - adjust some coding style crypto: hisilicon/hpre - fix a bug in dh algorithm drivers/crypto/hisilicon/hpre/hpre.h| 1 - drivers/crypto/hisilicon/hpre/hpre_crypto.c | 23 +++ 2 files changed, 11 insertions(+), 13 deletions(-) -- 2.8.1
[PATCH v2 1/3] crypto: hisilicon/hpre - remove useless code
From: Meng Yu
1. Remove unused member 'debug_root' in 'struct hpre_debug';
2. The u64 cast is redundant in 'cpu_to_le64'.
Fixes: 848974151618("crypto: hisilicon - Add debugfs for HPRE")
Fixes: dadbe4c11753("crypto: hisilicon/hpre - update debugfs ...")
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre.h| 1 -
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 8
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre.h
b/drivers/crypto/hisilicon/hpre/hpre.h
index ed730d1..f69252b 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -56,7 +56,6 @@ struct hpre_dfx {
* Just relevant for PF.
*/
struct hpre_debug {
- struct dentry *debug_root;
struct hpre_dfx dfx[HPRE_DFX_FILE_NUM];
struct hpre_debugfs_file files[HPRE_DEBUGFS_FILE_NUM];
};
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index d685992..678a5ee 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -474,7 +474,7 @@ static int hpre_msg_request_set(struct hpre_ctx *ctx, void
*req, bool is_rsa)
h_req->areq.dh = kreq;
msg = _req->req;
memset(msg, 0, sizeof(*msg));
- msg->key = cpu_to_le64((u64)ctx->dh.dma_xa_p);
+ msg->key = cpu_to_le64(ctx->dh.dma_xa_p);
}
msg->dw0 |= cpu_to_le32(0x1 << HPRE_SQE_DONE_SHIFT);
@@ -740,7 +740,7 @@ static int hpre_rsa_enc(struct akcipher_request *req)
return ret;
msg->dw0 |= cpu_to_le32(HPRE_ALG_NC_NCRT);
- msg->key = cpu_to_le64((u64)ctx->rsa.dma_pubkey);
+ msg->key = cpu_to_le64(ctx->rsa.dma_pubkey);
ret = hpre_hw_data_init(hpre_req, req->src, req->src_len, 1, 0);
if (unlikely(ret))
@@ -788,11 +788,11 @@ static int hpre_rsa_dec(struct akcipher_request *req)
return ret;
if (ctx->crt_g2_mode) {
- msg->key = cpu_to_le64((u64)ctx->rsa.dma_crt_prikey);
+ msg->key = cpu_to_le64(ctx->rsa.dma_crt_prikey);
msg->dw0 = cpu_to_le32(le32_to_cpu(msg->dw0) |
HPRE_ALG_NC_CRT);
} else {
- msg->key = cpu_to_le64((u64)ctx->rsa.dma_prikey);
+ msg->key = cpu_to_le64(ctx->rsa.dma_prikey);
msg->dw0 = cpu_to_le32(le32_to_cpu(msg->dw0) |
HPRE_ALG_NC_NCRT);
}
--
2.8.1
[PATCH v2 3/3] crypto: hisilicon/hpre - fix a bug in dh algorithm
From: Meng Yu
Using 'g' not equal to 2 in dh algorithm may cause an error like this:
arm-smmu-v3 arm-smmu-v3.1.auto: event 0x10 received:
dh: Party A: generate public key test failed. err -22
11375.065672] dh alg: dh: test failed on vector 1, err=-22
arm-smmu-v3 arm-smmu-v3.1.auto: 0x7910
arm-smmu-v3 arm-smmu-v3.1.auto: 0x12080080
hpre-dh self test failed
arm-smmu-v3 arm-smmu-v3.1.auto: 0x
arm-smmu-v3 arm-smmu-v3.1.auto: 0x
arm-smmu-v3 arm-smmu-v3.1.auto: event 0x10 received:
arm-smmu-v3 arm-smmu-v3.1.auto: 0x7910
arm-smmu-v3 arm-smmu-v3.1.auto: 0x12080083
arm-smmu-v3 arm-smmu-v3.1.auto: 0x00c0
arm-smmu-v3 arm-smmu-v3.1.auto: 0x
arm-smmu-v3 arm-smmu-v3.1.auto: event 0x10 received:
arm-smmu-v3 arm-smmu-v3.1.auto: 0x7910
arm-smmu-v3 arm-smmu-v3.1.auto: 0x12080081
arm-smmu-v3 arm-smmu-v3.1.auto: 0x0040
arm-smmu-v3 arm-smmu-v3.1.auto: 0x
arm-smmu-v3 arm-smmu-v3.1.auto: event 0x10 received:
arm-smmu-v3 arm-smmu-v3.1.auto: 0x7910
arm-smmu-v3 arm-smmu-v3.1.auto: 0x12080082
arm-smmu-v3 arm-smmu-v3.1.auto: 0x0080
arm-smmu-v3 arm-smmu-v3.1.auto: 0x
hisi_hpre :79:00.0: dat_rd_poison_int_set [error status=0x8] found
hisi_hpre :79:00.0: ooo_rdrsp_err_int_set [error status=0xfc00] found
hisi_hpre :79:00.0: Controller resetting...
hisi_hpre :79:00.0: Controller reset complete
{2}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0
{2}[Hardware Error]: event severity: recoverable
{2}[Hardware Error]: Error 0, type: recoverable
{2}[Hardware Error]: section type: unknown, c8b328a8-9917-4af6-9a13-2e08ab2e7586
{2}[Hardware Error]: section length: 0x4c
as we missed initiating 'msg->in'.
Fixes: c8b4b477079d("crypto: hisilicon - add HiSilicon HPRE accelerator")
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index 8bdaca0..a87f990 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -528,6 +528,8 @@ static int hpre_dh_compute_value(struct kpp_request *req)
ret = hpre_hw_data_init(hpre_req, req->src, req->src_len, 1, 1);
if (unlikely(ret))
goto clear_all;
+ } else {
+ msg->in = cpu_to_le64(ctx->dh.dma_g);
}
ret = hpre_hw_data_init(hpre_req, req->dst, req->dst_len, 0, 1);
--
2.8.1
[PATCH v2 2/3] crypto: hisilicon/hpre - adjust some coding style
From: Meng Yu
Adjust some coding style to make code aligned.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index 678a5ee..8bdaca0 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -188,8 +188,7 @@ static int hpre_get_data_dma_addr(struct hpre_asym_request
*hpre_req,
hpre_req->dst = NULL;
dma_dir = DMA_FROM_DEVICE;
}
- *tmp = dma_map_single(dev, sg_virt(data),
- len, dma_dir);
+ *tmp = dma_map_single(dev, sg_virt(data), len, dma_dir);
if (unlikely(dma_mapping_error(dev, *tmp))) {
dev_err(dev, "dma map data err!\n");
return -ENOMEM;
@@ -239,8 +238,8 @@ static int hpre_hw_data_init(struct hpre_asym_request
*hpre_req,
((is_dh && !is_src) || !is_dh))
ret = hpre_get_data_dma_addr(hpre_req, data, len, is_src, );
else
- ret = hpre_prepare_dma_buf(hpre_req, data, len,
- is_src, );
+ ret = hpre_prepare_dma_buf(hpre_req, data, len, is_src, );
+
if (unlikely(ret))
return ret;
@@ -267,11 +266,9 @@ static void hpre_hw_data_clr_all(struct hpre_ctx *ctx,
if (src) {
if (req->src)
- dma_free_coherent(dev, ctx->key_sz,
- req->src, tmp);
+ dma_free_coherent(dev, ctx->key_sz, req->src, tmp);
else
- dma_unmap_single(dev, tmp,
-ctx->key_sz, DMA_TO_DEVICE);
+ dma_unmap_single(dev, tmp, ctx->key_sz, DMA_TO_DEVICE);
}
tmp = le64_to_cpu(sqe->out);
--
2.8.1
Re: [PATCH 3/3] crypto: hisilicon/hpre - fix a bug in dh algorithm
Yes, 'u64' is redundant, I will resend one!
Thank you!
On 2020/9/18 15:11, Herbert Xu wrote:
On Thu, Sep 10, 2020 at 07:25:22PM +0800, Meng Yu wrote:
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index 0cbe99a1..2d91593 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -528,6 +528,8 @@ static int hpre_dh_compute_value(struct kpp_request *req)
ret = hpre_hw_data_init(hpre_req, req->src, req->src_len, 1, 1);
if (unlikely(ret))
goto clear_all;
+ } else {
+ msg->in = cpu_to_le64((u64)ctx->dh.dma_g);
Why do you need the u64 cast?
Cheers,
