[PATCH] crypto: vmx -- disable preemption to enable vsx in aes_ctr.c
Some preemptible check warnings were reported from enable_kernel_vsx(). This
patch disables preemption in aes_ctr.c before enabling vsx, and they are now
consistent with other files in the same directory.
Signed-off-by: Li Zhong
---
drivers/crypto/vmx/aes_ctr.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/crypto/vmx/aes_ctr.c b/drivers/crypto/vmx/aes_ctr.c
index 38ed10d..7cf6d31 100644
--- a/drivers/crypto/vmx/aes_ctr.c
+++ b/drivers/crypto/vmx/aes_ctr.c
@@ -80,11 +80,13 @@ static int p8_aes_ctr_setkey(struct crypto_tfm *tfm, const
u8 *key,
int ret;
struct p8_aes_ctr_ctx *ctx = crypto_tfm_ctx(tfm);
+ preempt_disable();
pagefault_disable();
enable_kernel_vsx();
ret = aes_p8_set_encrypt_key(key, keylen * 8, &ctx->enc_key);
disable_kernel_vsx();
pagefault_enable();
+ preempt_enable();
ret += crypto_blkcipher_setkey(ctx->fallback, key, keylen);
return ret;
@@ -99,11 +101,13 @@ static void p8_aes_ctr_final(struct p8_aes_ctr_ctx *ctx,
u8 *dst = walk->dst.virt.addr;
unsigned int nbytes = walk->nbytes;
+ preempt_disable();
pagefault_disable();
enable_kernel_vsx();
aes_p8_encrypt(ctrblk, keystream, &ctx->enc_key);
disable_kernel_vsx();
pagefault_enable();
+ preempt_enable();
crypto_xor(keystream, src, nbytes);
memcpy(dst, keystream, nbytes);
@@ -132,6 +136,7 @@ static int p8_aes_ctr_crypt(struct blkcipher_desc *desc,
blkcipher_walk_init(&walk, dst, src, nbytes);
ret = blkcipher_walk_virt_block(desc, &walk, AES_BLOCK_SIZE);
while ((nbytes = walk.nbytes) >= AES_BLOCK_SIZE) {
+ preempt_disable();
pagefault_disable();
enable_kernel_vsx();
aes_p8_ctr32_encrypt_blocks(walk.src.virt.addr,
@@ -143,6 +148,7 @@ static int p8_aes_ctr_crypt(struct blkcipher_desc *desc,
walk.iv);
disable_kernel_vsx();
pagefault_enable();
+ preempt_enable();
/* We need to update IV mostly for last bytes/round */
inc = (nbytes & AES_BLOCK_MASK) / AES_BLOCK_SIZE;
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Introduce AMD Secure Processor device
On Thu, Jan 19, 2017 at 02:03:12PM -0600, Brijesh Singh wrote: > Hi Greg, > > On 01/19/2017 12:21 PM, Greg KH wrote: > > On Thu, Jan 19, 2017 at 01:07:50PM -0500, Brijesh Singh wrote: > > > The CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure > > > Processor, > > > which is not dedicated solely to crypto. The AMD Secure Processor includes > > > CCP and PSP (Platform Secure Processor) devices. > > > > > > This patch series moves the CCP device driver to the misc directory and > > > creates a framework that allows functional component of the AMD Secure > > > Processor to be initialized and handled appropriately. > > > > Why the misc directory? I don't see the justification here... > > > > Since this driver is not solely for crypto purposes and do not fit in any of > the standard categories hence I thought of moving it into misc directory. I > am open to other suggestions unless Herbert is ok with leaving it into > crypto and allowing the addition of the Secure Processor support. > > The patch series allows the CCP driver to support other Secure Processor > functions, e.g Secure Encrypted Virtualization (SEV) key management. In > past, I tried to add SEV support into existing CCP driver [1] but we quickly > learned that CCP driver should be moved outside the crypto directory > otherwise will end up adding non crypto code into drivers/crypto directory. > Once this cleanup is accepted then I can work to add SEV support inside the > CCP driver. > > [1] http://marc.info/?l=linux-kernel&m=147204118426151&w=2 Ok, what type of interface will this driver have with userspace and/or other parts of the kernel? Is there a misc char device burried in there somewhere (I couldn't find it in the big diff sent out), or is this driver just creating specific apis that other parts of the kernel will call if available? I think we need to see more code here, broken up into sane and reviewable pieces, before we could either say "No don't do that!" or "sure, let me go merge these!" :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] crypto: tcrypt: add ECDSA test modes
Update tcrypt module to include a new ECDSA test
modes. It includes:
tcrypt.ko mode=560 for ECDSA sign/verify validation.
tcrypt.ko mode=561 for ECDSA sign/verify op perf in cycles.
tcrypt.ko mode=561 sec= for number of ECDSA sign
verify ops in given time.
Signed-off-by: Nitin Kumbhar
---
crypto/tcrypt.c | 250 ++-
crypto/tcrypt.h | 122 +++
2 files changed, 368 insertions(+), 4 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index ae22f05d5936..0e4547fe23a8 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -7,6 +7,7 @@
* Copyright (c) 2002 James Morris
* Copyright (c) 2002 Jean-Francois Dive
* Copyright (c) 2007 Nokia Siemens Networks
+ * Copyright (c) 2017 NVIDIA Corporation
*
* Updated RFC4106 AES-GCM testing.
*Authors: Aidan O'Mahony (aidan.o.mah...@intel.com)
@@ -25,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -44,10 +46,12 @@
#define TVMEMSIZE 4
/*
-* Used by test_cipher_speed()
-*/
-#define ENCRYPT 1
-#define DECRYPT 0
+ * Used by test_cipher_speed()
+ */
+#define DECRYPT0
+#define ENCRYPT1
+#define SIGN 2
+#define VERIFY 3
#define MAX_DIGEST_SIZE64
@@ -994,6 +998,223 @@ static void test_cipher_speed(const char *algo, int enc,
unsigned int secs,
false);
}
+static inline int do_one_akcipher_op(struct akcipher_request *r, int ret)
+{
+ if (ret == -EINPROGRESS || ret == -EBUSY) {
+ struct tcrypt_result *tr = r->base.data;
+
+ wait_for_completion(&tr->completion);
+ reinit_completion(&tr->completion);
+ ret = tr->err;
+ }
+ return ret;
+}
+
+static int test_akcipher_jiffies(struct akcipher_request *r, int op, int secs)
+{
+ unsigned long start, end;
+ int count, ret;
+
+ for (start = jiffies, end = start + secs * HZ, count = 0;
+time_before(jiffies, end); count++) {
+
+ switch (op) {
+ case SIGN:
+ ret = do_one_akcipher_op(r, crypto_akcipher_sign(r));
+ break;
+ case VERIFY:
+ ret = do_one_akcipher_op(r, crypto_akcipher_verify(r));
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ if (ret)
+ return ret;
+ }
+
+ pr_info("%d operations in %d seconds\n", count, secs);
+ return 0;
+}
+
+static int test_akcipher_cycles(struct akcipher_request *r, int op)
+{
+ unsigned long cycles = 0;
+ int ret = 0;
+ int i;
+
+ /* Warm-up run. */
+ for (i = 0; i < 4; i++) {
+ switch (op) {
+ case SIGN:
+ ret = do_one_akcipher_op(r, crypto_akcipher_sign(r));
+ break;
+ case VERIFY:
+ ret = do_one_akcipher_op(r, crypto_akcipher_verify(r));
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ if (ret)
+ goto out;
+ }
+
+ /* The real thing. */
+ for (i = 0; i < 8; i++) {
+ cycles_t start, end;
+
+ start = get_cycles();
+ switch (op) {
+ case SIGN:
+ ret = do_one_akcipher_op(r, crypto_akcipher_sign(r));
+ break;
+ case VERIFY:
+ ret = do_one_akcipher_op(r, crypto_akcipher_verify(r));
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ end = get_cycles();
+
+ if (ret)
+ goto out;
+
+ cycles += end - start;
+ }
+out:
+ if (ret == 0)
+ pr_info("1 operation in %lu cycles\n", (cycles + 4) / 8);
+
+ return ret;
+}
+
+static void test_akcipher_speed(const char *algo, int op, unsigned int secs,
+ struct akcipher_speed_template *template,
+ unsigned int tcount, u8 *keysize)
+{
+ unsigned int ret, i, j;
+ struct tcrypt_result tresult;
+ const char *key;
+ struct akcipher_request *req;
+ struct crypto_akcipher *tfm;
+ unsigned int m_size = 0;
+ unsigned int nbytes = 0;
+ const char *o;
+
+ if (op == SIGN)
+ o = "sign";
+ else if (op == VERIFY)
+ o = "verify";
+ else
+ return;
+
+ tfm = crypto_alloc_akcipher(algo, 0, 0);
+ if (IS_ERR(tfm)) {
+ pr_err("failed to load transform for %s: %ld\n", algo,
+
[PATCH 1/6] crypto: ecc: separate out ecc and ecdh
Add ECC operations i.e. vli and ecc point ops as a separate
module under CRYPTO_ECC kconfig. This allows other ECC
algorithms like ECDSA & ECIES to reuse these ops even when ECDH
is disabled with CRYPTO_ECDH kconfig.
With these changes, ECDH specific functions are consolidated
as ECDH helper routines and ECC curves are moved to ECC specific
files.
Signed-off-by: Nitin Kumbhar
---
crypto/Kconfig |7 +++
crypto/Makefile |5 +-
crypto/ecc.c| 133 ++
crypto/ecc.h| 45 ++--
crypto/ecc_curve_defs.h | 51 --
crypto/ecc_ecdh.h | 54 +++
crypto/ecdh.c |4 +-
crypto/ecdh_helper.c| 94 +
include/crypto/ecc.h| 24 +
include/crypto/ecdh.h | 10 +---
10 files changed, 243 insertions(+), 184 deletions(-)
create mode 100644 crypto/ecc_ecdh.h
create mode 100644 include/crypto/ecc.h
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 160f08e721cc..e240075d6f46 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -127,9 +127,16 @@ config CRYPTO_DH
help
Generic implementation of the Diffie-Hellman algorithm.
+config CRYPTO_ECC
+ tristate "ECC functions"
+ help
+ Implementation of ECC functions
+
+
config CRYPTO_ECDH
tristate "ECDH algorithm"
select CRYTPO_KPP
+ select CRYPTO_ECC
help
Generic implementation of the ECDH algorithm
diff --git a/crypto/Makefile b/crypto/Makefile
index b8f0e3eb0791..827740a47a37 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -33,8 +33,9 @@ obj-$(CONFIG_CRYPTO_KPP2) += kpp.o
dh_generic-y := dh.o
dh_generic-y += dh_helper.o
obj-$(CONFIG_CRYPTO_DH) += dh_generic.o
-ecdh_generic-y := ecc.o
-ecdh_generic-y += ecdh.o
+
+obj-$(CONFIG_CRYPTO_ECC) += ecc.o
+ecdh_generic-y := ecdh.o
ecdh_generic-y += ecdh_helper.o
obj-$(CONFIG_CRYPTO_ECDH) += ecdh_generic.o
diff --git a/crypto/ecc.c b/crypto/ecc.c
index 414c78a9c214..a8c10e725138 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -1,6 +1,7 @@
/*
* Copyright (c) 2013, Kenneth MacKay
* All rights reserved.
+ * Copyright (c) 2017, NVIDIA Corporation. All Rights Reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are
@@ -28,16 +29,54 @@
#include
#include
#include
-#include
#include "ecc.h"
-#include "ecc_curve_defs.h"
typedef struct {
u64 m_low;
u64 m_high;
} uint128_t;
+/* NIST P-192 */
+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 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
+};
+
+/* NIST P-256 */
+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 struct ecc_curve nist_p256 = {
+ .name = "nist_256",
+ .g = {
+ .x = nist_p256_g_x,
+ .y = nist_p256_g_y,
+ .ndigits = 4,
+ },
+ .p = nist_p256_p,
+ .n = nist_p256_n
+};
+
static inline const struct ecc_curve *ecc_get_curve(unsigned int curve_id)
{
switch (curve_id) {
@@ -926,93 +965,3 @@ int ecc_is_key_valid(unsigned int curve_id, unsigned int
ndigits,
return 0;
}
-
-int ecdh_make_pub_key(unsigned int curve_id, unsigned int ndigits,
- const u8 *private_key, unsigned int private_key_len,
- u8 *public_key, unsigned int public_key_len)
-{
- int ret = 0;
- struct ecc_point *pk;
- u64 priv[ndigits];
- unsigned int nbytes;
- const struct ecc_curve *curve = ecc_get_curve(curve_id);
-
- if (!private_key || !curve) {
- ret = -EINVAL;
-
[PATCH 0/6] Add support for ECDSA algorithm
Hello, This patch series adds support for Elliptic Curve Digital Signature Algorithm (ECDSA). To reuse existing ECC functionality, which is added as part of ECDH, it separates out ECC and ECDH so that only ECC functionality is available for ECDSA even when ECDH is in a disabled state. Patch #1 restructures ECC and ECDH code such that ECC is not dependent on ECDH config. Patches #2 & #3 add vli and ecc functions which are required for other Elliptic curve algorithms like ECDSA and ECIES. Patch #4 adds support for ECDSA. This has been validated for P192 and P256 elliptic curves. Patches #5 and #6 add ECDSA tests to validate ECDSA functionality and measure ECDSA performance. Nitin Kumbhar (6): crypto: ecc: separate out ecc and ecdh crypto: ecc: add vli and ecc ops crypto: ecc: export vli and ecc ops crypto: ecdsa: add ECDSA SW implementation crypto: testmgr: add ECDSA tests crypto: tcrypt: add ECDSA test modes crypto/Kconfig| 14 ++ crypto/Makefile |8 +- crypto/ecc.c | 415 - crypto/ecc.h | 98 ++ crypto/ecc_curve_defs.h | 51 + crypto/ecc_ecdh.h | 54 ++ crypto/ecdh.c |4 +- crypto/ecdh_helper.c | 94 ++ crypto/ecdsa.c| 331 + crypto/ecdsa_helper.c | 116 crypto/tcrypt.c | 250 - crypto/tcrypt.h | 122 crypto/testmgr.c | 452 - crypto/testmgr.h | 140 ++ include/crypto/akcipher.h |5 +- include/crypto/ecc.h | 24 +++ include/crypto/ecdh.h | 10 +- include/crypto/ecdsa.h| 29 +++ 18 files changed, 1984 insertions(+), 233 deletions(-) create mode 100644 crypto/ecc_ecdh.h create mode 100644 crypto/ecdsa.c create mode 100644 crypto/ecdsa_helper.c create mode 100644 include/crypto/ecc.h create mode 100644 include/crypto/ecdsa.h -- 1.7.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] crypto: ecc: export vli and ecc ops
Export vli and ECC related functions so that these can
be used by all ECC algorithm modules like ECDH, ECDSA and ECIES.
Signed-off-by: Nitin Kumbhar
---
crypto/ecc.c | 114 +-
crypto/ecc.h | 53 +++
2 files changed, 126 insertions(+), 41 deletions(-)
diff --git a/crypto/ecc.c b/crypto/ecc.c
index 6ad785c4c12a..c6fe1b7b998d 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -77,7 +77,7 @@
.n = nist_p256_n
};
-static inline const struct ecc_curve *ecc_get_curve(unsigned int curve_id)
+const struct ecc_curve *ecc_get_curve(unsigned int curve_id)
{
switch (curve_id) {
/* In FIPS mode only allow P256 and higher */
@@ -89,6 +89,7 @@
return NULL;
}
}
+EXPORT_SYMBOL_GPL(ecc_get_curve);
static u64 *ecc_alloc_digits_space(unsigned int ndigits)
{
@@ -105,7 +106,7 @@ static void ecc_free_digits_space(u64 *space)
kzfree(space);
}
-static struct ecc_point *ecc_alloc_point(unsigned int ndigits)
+struct ecc_point *ecc_alloc_point(unsigned int ndigits)
{
struct ecc_point *p = kmalloc(sizeof(*p), GFP_KERNEL);
@@ -130,8 +131,9 @@ static void ecc_free_digits_space(u64 *space)
kfree(p);
return NULL;
}
+EXPORT_SYMBOL_GPL(ecc_alloc_point);
-static void ecc_free_point(struct ecc_point *p)
+void ecc_free_point(struct ecc_point *p)
{
if (!p)
return;
@@ -140,17 +142,19 @@ static void ecc_free_point(struct ecc_point *p)
kzfree(p->y);
kzfree(p);
}
+EXPORT_SYMBOL_GPL(ecc_free_point);
-static void vli_clear(u64 *vli, unsigned int ndigits)
+void vli_clear(u64 *vli, unsigned int ndigits)
{
int i;
for (i = 0; i < ndigits; i++)
vli[i] = 0;
}
+EXPORT_SYMBOL_GPL(vli_clear);
/* Returns true if vli == 0, false otherwise. */
-static bool vli_is_zero(const u64 *vli, unsigned int ndigits)
+bool vli_is_zero(const u64 *vli, unsigned int ndigits)
{
int i;
@@ -161,15 +165,17 @@ static bool vli_is_zero(const u64 *vli, unsigned int
ndigits)
return true;
}
+EXPORT_SYMBOL_GPL(vli_is_zero);
/* Returns nonzero if bit bit of vli is set. */
-static u64 vli_test_bit(const u64 *vli, unsigned int bit)
+u64 vli_test_bit(const u64 *vli, unsigned int bit)
{
return (vli[bit / 64] & ((u64)1 << (bit % 64)));
}
+EXPORT_SYMBOL_GPL(vli_test_bit);
/* Counts the number of 64-bit "digits" in vli. */
-static unsigned int vli_num_digits(const u64 *vli, unsigned int ndigits)
+unsigned int vli_num_digits(const u64 *vli, unsigned int ndigits)
{
int i;
@@ -181,9 +187,10 @@ static unsigned int vli_num_digits(const u64 *vli,
unsigned int ndigits)
return (i + 1);
}
+EXPORT_SYMBOL_GPL(vli_num_digits);
/* Counts the number of bits required for vli. */
-static unsigned int vli_num_bits(const u64 *vli, unsigned int ndigits)
+unsigned int vli_num_bits(const u64 *vli, unsigned int ndigits)
{
unsigned int i, num_digits;
u64 digit;
@@ -198,15 +205,17 @@ static unsigned int vli_num_bits(const u64 *vli, unsigned
int ndigits)
return ((num_digits - 1) * 64 + i);
}
+EXPORT_SYMBOL_GPL(vli_num_bits);
/* Sets dest = src. */
-static void vli_set(u64 *dest, const u64 *src, unsigned int ndigits)
+void vli_set(u64 *dest, const u64 *src, unsigned int ndigits)
{
int i;
for (i = 0; i < ndigits; i++)
dest[i] = src[i];
}
+EXPORT_SYMBOL_GPL(vli_set);
/* Copy from vli to buf.
* For buffers smaller than vli: copy only LSB nbytes from vli.
@@ -225,6 +234,7 @@ void vli_copy_to_buf(u8 *dst_buf, unsigned int buf_len,
for (; i < buf_len; i++)
dst_buf[i] = 0;
}
+EXPORT_SYMBOL_GPL(vli_copy_to_buf);
/* Copy from buffer to vli.
* For buffers smaller than vli: fill up remaining vli with zeroes.
@@ -243,9 +253,10 @@ void vli_copy_from_buf(u64 *dst_vli, unsigned int ndigits,
for (; i < nbytes; i++)
vli[i] = 0;
}
+EXPORT_SYMBOL_GPL(vli_copy_from_buf);
/* Returns sign of left - right. */
-static int vli_cmp(const u64 *left, const u64 *right, unsigned int ndigits)
+int vli_cmp(const u64 *left, const u64 *right, unsigned int ndigits)
{
int i;
@@ -258,12 +269,13 @@ static int vli_cmp(const u64 *left, const u64 *right,
unsigned int ndigits)
return 0;
}
+EXPORT_SYMBOL_GPL(vli_cmp);
/* Computes result = in << c, returning carry. Can modify in place
* (if result == in). 0 < shift < 64.
*/
-static u64 vli_lshift(u64 *result, const u64 *in, unsigned int shift,
- unsigned int ndigits)
+u64 vli_lshift(u64 *result, const u64 *in, unsigned int shift,
+ unsigned int ndigits)
{
u64 carry = 0;
int i;
@@ -277,9 +289,10 @@ static u64 vli_lshift(u64 *result, const u64 *in, unsigned
int shift,
return carry;
}
+EXPORT_SYMBOL_GPL(vli_lshift);
/* Computes vli = vli >> 1. */
-static void vli_rshift1(u6
[PATCH 4/6] crypto: ecdsa: add ECDSA SW implementation
This adds support for ECDSA algorithm. This implementation supports
sign and verify functions for ECDSA algorithm using akcipher. As ECDSA
is a signing algorithm dummy functions are added for encrypt() and
decrypt().
Helper routines for parsing public and private ECC keys for ECDSA are
added as well.
Signed-off-by: Nitin Kumbhar
---
crypto/Kconfig|7 +
crypto/Makefile |3 +
crypto/ecdsa.c| 331 +
crypto/ecdsa_helper.c | 116
include/crypto/akcipher.h |5 +-
include/crypto/ecdsa.h| 29
6 files changed, 490 insertions(+), 1 deletions(-)
create mode 100644 crypto/ecdsa.c
create mode 100644 crypto/ecdsa_helper.c
create mode 100644 include/crypto/ecdsa.h
diff --git a/crypto/Kconfig b/crypto/Kconfig
index e240075d6f46..1c5c236b3bbc 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -140,6 +140,13 @@ config CRYPTO_ECDH
help
Generic implementation of the ECDH algorithm
+config CRYPTO_ECDSA
+ tristate "ECDSA algorithm"
+ select CRYPTO_AKCIPHER
+ select CRYPTO_ECC
+ help
+ Generic implementation of the ECDSA algorithm
+
config CRYPTO_MANAGER
tristate "Cryptographic algorithm manager"
select CRYPTO_MANAGER2
diff --git a/crypto/Makefile b/crypto/Makefile
index 827740a47a37..9c13eb2ade6a 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -38,6 +38,9 @@ obj-$(CONFIG_CRYPTO_ECC) += ecc.o
ecdh_generic-y := ecdh.o
ecdh_generic-y += ecdh_helper.o
obj-$(CONFIG_CRYPTO_ECDH) += ecdh_generic.o
+ecdsa_generic-y := ecdsa.o
+ecdsa_generic-y += ecdsa_helper.o
+obj-$(CONFIG_CRYPTO_ECDSA) += ecdsa_generic.o
$(obj)/rsapubkey-asn1.o: $(obj)/rsapubkey-asn1.c $(obj)/rsapubkey-asn1.h
$(obj)/rsaprivkey-asn1.o: $(obj)/rsaprivkey-asn1.c $(obj)/rsaprivkey-asn1.h
diff --git a/crypto/ecdsa.c b/crypto/ecdsa.c
new file mode 100644
index ..d415900af3bd
--- /dev/null
+++ b/crypto/ecdsa.c
@@ -0,0 +1,331 @@
+/*
+ * ECDSA generic algorithm
+ *
+ * Copyright (c) 2017, NVIDIA Corporation. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ecc.h"
+
+struct ecdsa_ctx {
+ unsigned int curve_id;
+ unsigned int ndigits;
+ u64 private_key[ECC_MAX_DIGITS];
+ u64 public_key[2 * ECC_MAX_DIGITS];
+};
+
+static inline struct ecdsa_ctx *ecdsa_get_ctx(struct crypto_akcipher *tfm)
+{
+ return akcipher_tfm_ctx(tfm);
+}
+
+static void ecdsa_parse_msg_hash(struct akcipher_request *req, u64 *msg,
+unsigned int ndigits)
+{
+ unsigned int nbytes = ndigits << ECC_DIGITS_TO_BYTES_SHIFT;
+ unsigned int hash_len, hash_off;
+ unsigned char *hash, *msg_ptr;
+ int i;
+
+ /*
+* If hash_len == nbytes:
+* copy nbytes from req
+* If hash_len > nbytes:
+* copy left most nbytes from hash ignoring LSBs
+* If hash_len < nbytes:
+* copy hash_len from req and zero remaining bytes
+* (nbytes - hash_len)
+*/
+ hash_len = req->src[0].length;
+ hash_off = hash_len <= nbytes ? 0 : hash_len - nbytes;
+
+ msg_ptr = (unsigned char *)msg;
+ hash = sg_virt(&req->src[0]);
+
+ for (i = hash_off; i < hash_len; i++)
+ *msg_ptr++ = hash[i];
+ for (; i < nbytes; i++)
+ *msg_ptr++ = 0;
+}
+
+int ecdsa_sign(struct akcipher_request *req)
+{
+ struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
+ struct ecdsa_ctx *ctx = ecdsa_get_ctx(tfm);
+ unsigned int ndigits = ctx->ndigits;
+ unsigned int nbytes = ndigits << ECC_DIGITS_TO_BYTES_SHIFT;
+ unsigned int curve_id = ctx->curve_id;
+ const struct ecc_curve *curve = ecc_get_curve(curve_id);
+ struct ecc_point *x1y1 = NULL;
+ u64 z[ndigits], d[ndigits];
+ u64 k[ndigits], k_inv[ndigits];
+ u64 r[ndigits], s[ndigits];
+ u64 dr[ndigits], zdr[ndigits];
+ u8 *r_ptr, *s_ptr;
+
+ if (req->dst_len < 2 * nbytes) {
+ req->dst_len = 2 * nbytes;
+ return -EINVAL;
+ }
+
+ ecdsa_parse_msg_hash(req, z, ndigits);
+
+ /* d */
+ vli_set(d, (const u64 *)ctx->private_key, ndigits);
+
+ /* k */
+#if defined(CONFIG_CRYPTO_MANAGER2)
+ if (req->info) {
+ vli_copy_from_buf(k, ndigits, req->info, nbytes);
+ } else
+#endif
+ get_random_bytes(k, nbytes);
+
+ x1y1 = ecc_alloc_point(ndigits);
+ if (!x1y1)
+ return -ENOMEM;
+
+ /* (x1, y1) = k x G */
+ ecc_point_mult(x1y1, &curve->g, k, NULL, curve->p, ndigit
[PATCH 5/6] crypto: testmgr: add ECDSA tests
Update crypto test manager to include NIST ECDSA
test vectors and various ECDSA tests. These include
tests for ECDSA signing, ECDSA sign-verification,
ECDSA signing and verifying generated signatures and
invalidation of incorrect signatures.
Signed-off-by: Nitin Kumbhar
---
crypto/testmgr.c | 452 +-
crypto/testmgr.h | 140 +
2 files changed, 589 insertions(+), 3 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 98eb09782db8..a1db28cbc32d 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -5,6 +5,7 @@
* Copyright (c) 2002 Jean-Francois Dive
* Copyright (c) 2007 Nokia Siemens Networks
* Copyright (c) 2008 Herbert Xu
+ * Copyright (c) 2017 NVIDIA Corporation
*
* Updated RFC4106 AES-GCM testing.
*Authors: Aidan O'Mahony (aidan.o.mah...@intel.com)
@@ -2085,6 +2086,436 @@ static int alg_test_kpp(const struct alg_test_desc
*desc, const char *driver,
return err;
}
+static int do_test_ecdsa_verify(struct crypto_akcipher *tfm,
+ struct akcipher_testvec *vec)
+{
+ struct akcipher_request *req = NULL;
+ u8 *r_str = NULL, *s_str = NULL;
+ u8 *m_str = NULL;
+ struct scatterlist src_tab[3], dst;
+ struct tcrypt_result result;
+ unsigned int outbuf_maxlen;
+ u8 *outbuf = NULL;
+ unsigned int nbytes;
+ int err;
+
+ /* Alloc akcipher request */
+ req = akcipher_request_alloc(tfm, GFP_KERNEL);
+ if (!req)
+ return -ENOMEM;
+
+ /* Set private key */
+ err = crypto_akcipher_set_pub_key(tfm, vec->key, vec->key_len);
+ if (err)
+ goto error;
+
+ /*
+* vec->c always contains k, R and S in that order. All are
+* of same size and are equal to n i.e. the order of
+* an elliptic curve.
+*/
+ nbytes = vec->c_size / 3;
+
+ r_str = kzalloc(nbytes, GFP_KERNEL);
+ s_str = kzalloc(nbytes, GFP_KERNEL);
+ m_str = kzalloc(vec->m_size, GFP_KERNEL);
+ if (!r_str || !s_str || !m_str) {
+ err = -ENOMEM;
+ goto error;
+ }
+ memcpy(r_str, (u8 *)vec->c + nbytes, nbytes);
+ memcpy(s_str, (u8 *)vec->c + 2 * nbytes, nbytes);
+ memcpy(m_str, vec->m, vec->m_size);
+
+ outbuf_maxlen = crypto_akcipher_maxsize(tfm);
+ if (outbuf_maxlen < 0) {
+ err = outbuf_maxlen;
+ goto error;
+ }
+ outbuf = kzalloc(outbuf_maxlen, GFP_KERNEL);
+ if (!outbuf) {
+ err = -ENOMEM;
+ goto error;
+ }
+
+ /* Set src and dst buffers */
+ sg_init_table(src_tab, 3);
+ sg_set_buf(&src_tab[0], m_str, vec->m_size);
+ sg_set_buf(&src_tab[1], r_str, nbytes);
+ sg_set_buf(&src_tab[2], s_str, nbytes);
+ sg_init_one(&dst, outbuf, outbuf_maxlen);
+
+ akcipher_request_set_crypt(req, src_tab, &dst,
+ vec->m_size + 2 * nbytes, outbuf_maxlen);
+
+ /* Set up result callback */
+ init_completion(&result.completion);
+ akcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
+ tcrypt_complete, &result);
+
+ /* Run ecdsa verify operation on sig (r,s) */
+ err = wait_async_op(&result, crypto_akcipher_verify(req));
+ if (err) {
+ pr_err("alg: ecdsa: verify(rs) test failed. err %d\n", err);
+ goto error;
+ }
+error:
+ akcipher_request_free(req);
+ kfree(r_str);
+ kfree(s_str);
+ kfree(m_str);
+ kfree(outbuf);
+ return err;
+}
+
+static int do_test_ecdsa_invalid_verify(struct crypto_akcipher *tfm,
+ struct akcipher_testvec *vec)
+{
+ struct akcipher_request *req = NULL;
+ u8 *r_str = NULL, *s_str = NULL;
+ u8 *m_str = NULL;
+ struct scatterlist src_tab[3], dst;
+ struct tcrypt_result result;
+ unsigned int outbuf_maxlen;
+ u8 *outbuf = NULL;
+ unsigned int nbytes;
+ int err;
+
+ /* Alloc akcipher request */
+ req = akcipher_request_alloc(tfm, GFP_KERNEL);
+ if (!req)
+ return -ENOMEM;
+
+ /* Set private key */
+ err = crypto_akcipher_set_pub_key(tfm, vec->key, vec->key_len);
+ if (err)
+ goto error;
+
+ /*
+* vec->c always contains k, R and S in that order. All are
+* of same size and are equal to n i.e. the order of
+* an elliptic curve.
+*/
+ nbytes = vec->c_size / 3;
+
+ r_str = kzalloc(nbytes, GFP_KERNEL);
+ s_str = kzalloc(nbytes, GFP_KERNEL);
+ m_str = kzalloc(vec->m_size, GFP_KERNEL);
+ if (!r_str || !s_str || !m_str) {
+ err = -ENOMEM;
+ goto error;
+ }
+ memcpy(r_str, (u8 *)vec->c + 1 * nbytes, nbytes);
+ memcpy(s_str, (u8 *)vec->c +
[PATCH 2/6] crypto: ecc: add vli and ecc ops
Add functions to copy vli from buffers, to print vli in
big endian format, for vli mod and mod multiplication ops
and ecc point addition.
Signed-off-by: Nitin Kumbhar
---
crypto/ecc.c | 168 ++
1 files changed, 168 insertions(+), 0 deletions(-)
diff --git a/crypto/ecc.c b/crypto/ecc.c
index a8c10e725138..6ad785c4c12a 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -208,6 +208,42 @@ static void vli_set(u64 *dest, const u64 *src, unsigned
int ndigits)
dest[i] = src[i];
}
+/* Copy from vli to buf.
+ * For buffers smaller than vli: copy only LSB nbytes from vli.
+ * For buffers larger than vli : fill up remaining buf with zeroes.
+ */
+void vli_copy_to_buf(u8 *dst_buf, unsigned int buf_len,
+const u64 *src_vli, unsigned int ndigits)
+{
+ unsigned int nbytes = ndigits << ECC_DIGITS_TO_BYTES_SHIFT;
+ u8 *vli = (u8 *)src_vli;
+ int i;
+
+ for (i = 0; i < buf_len && i < nbytes; i++)
+ dst_buf[i] = vli[i];
+
+ for (; i < buf_len; i++)
+ dst_buf[i] = 0;
+}
+
+/* Copy from buffer to vli.
+ * For buffers smaller than vli: fill up remaining vli with zeroes.
+ * For buffers larger than vli : copy only LSB nbytes to vli.
+ */
+void vli_copy_from_buf(u64 *dst_vli, unsigned int ndigits,
+ const u8 *src_buf, unsigned int buf_len)
+{
+ unsigned int nbytes = ndigits << ECC_DIGITS_TO_BYTES_SHIFT;
+ u8 *vli = (u8 *)dst_vli;
+ int i;
+
+ for (i = 0; i < buf_len && i < nbytes; i++)
+ vli[i] = src_buf[i];
+
+ for (; i < nbytes; i++)
+ vli[i] = 0;
+}
+
/* Returns sign of left - right. */
static int vli_cmp(const u64 *left, const u64 *right, unsigned int ndigits)
{
@@ -440,6 +476,83 @@ static void vli_mod_sub(u64 *result, const u64 *left,
const u64 *right,
vli_add(result, result, mod, ndigits);
}
+/* Computes result = input % mod.
+ * Assumes that input < mod, result != mod.
+ */
+void vli_mod(u64 *result, const u64 *input, const u64 *mod,
+unsigned int ndigits)
+{
+ if (vli_cmp(input, mod, ndigits) >= 0)
+ vli_sub(result, input, mod, ndigits);
+ else
+ vli_set(result, input, ndigits);
+}
+
+/* Print vli in big-endian format.
+ * The bytes are printed in hex.
+ */
+void vli_print(char *vli_name, const u64 *vli, unsigned int ndigits)
+{
+ int nbytes = ndigits << ECC_DIGITS_TO_BYTES_SHIFT;
+ int buf_size = 2 * ECC_MAX_DIGIT_BYTES + 1;
+ unsigned char *c, buf[buf_size];
+ int i, j;
+
+ c = (unsigned char *)vli;
+
+ for (i = nbytes - 1, j = 0; i >= 0 && j < buf_size; i--, j += 2)
+ snprintf(&buf[j], 3, "%02x", *(c + i));
+
+ buf[j] = '\0';
+
+ pr_info("%20s(BigEnd)=%s\n", vli_name, buf);
+}
+
+/* Computes result = (left * right) % mod.
+ * Assumes that left < mod and right < mod, result != mod.
+ * Uses:
+ * (a * b) % m = ((a % m) * (b % m)) % m
+ * (a * b) % m = (a + a + ... + a) % m = b modular additions of (a % m)
+ */
+void vli_mod_mult(u64 *result, const u64 *left, const u64 *right,
+ const u64 *mod, unsigned int ndigits)
+{
+ u64 t1[ndigits], mm[ndigits];
+ u64 aa[ndigits], bb[ndigits];
+
+ vli_clear(result, ndigits);
+ vli_set(aa, left, ndigits);
+ vli_set(bb, right, ndigits);
+ vli_set(mm, mod, ndigits);
+
+ /* aa = aa % mm */
+ vli_mod(aa, aa, mm, ndigits);
+
+ /* bb = bb % mm */
+ vli_mod(bb, bb, mm, ndigits);
+
+ while (!vli_is_zero(bb, ndigits)) {
+
+ /* if bb is odd i.e. 0th bit set then add
+* aa i.e. result = (result + aa) % mm
+*/
+ if (vli_test_bit(bb, 0))
+ vli_mod_add(result, result, aa, mm, ndigits);
+
+ /* bb = bb / 2 = bb >> 1 */
+ vli_rshift1(bb, ndigits);
+
+ /* aa = (aa * 2) % mm */
+ vli_sub(t1, mm, aa, ndigits);
+ if (vli_cmp(aa, t1, ndigits) == -1)
+ /* if aa < t1 then aa = aa * 2 = aa << 1*/
+ vli_lshift(aa, aa, 1, ndigits);
+ else
+ /* if aa >= t1 then aa = aa - t1 */
+ vli_sub(aa, aa, t1, ndigits);
+ }
+}
+
/* Computes p_result = p_product % curve_p.
* See algorithm 5 and 6 from
* http://www.isys.uni-klu.ac.at/PDF/2001-0126-MT.pdf
@@ -878,6 +991,61 @@ static void xycz_add_c(u64 *x1, u64 *y1, u64 *x2, u64 *y2,
u64 *curve_prime,
vli_set(x1, t7, ndigits);
}
+/* Point addition.
+ * Add 2 distinct points on elliptic curve to get a new point.
+ *
+ * P = (x1,y1)and Q = (x2, y2) then P + Q = (x3,y3) where
+ * x3 = ((y2-y1)/(x2-x1))^2 - x1 - x2
+ * y3 = ((y2-y1)/(x2-x1))(x1-x3) - y1
+ *
+ * Q => P + Q
+ */
+void ecc_point_add(u64 *x1, u64 *y1, u64 *x2, u64 *y2, u64 *curve_prime,
+
Re: [PATCH 4/6] crypto: ecdsa: add ECDSA SW implementation
Am Freitag, 20. Januar 2017, 17:05:59 CET schrieb Nitin Kumbhar:
Hi Nitin,
> This adds support for ECDSA algorithm. This implementation supports
> sign and verify functions for ECDSA algorithm using akcipher. As ECDSA
> is a signing algorithm dummy functions are added for encrypt() and
> decrypt().
>
> Helper routines for parsing public and private ECC keys for ECDSA are
> added as well.
>
> Signed-off-by: Nitin Kumbhar
> ---
> crypto/Kconfig|7 +
> crypto/Makefile |3 +
> crypto/ecdsa.c| 331
> + crypto/ecdsa_helper.c |
> 116
> include/crypto/akcipher.h |5 +-
> include/crypto/ecdsa.h| 29
> 6 files changed, 490 insertions(+), 1 deletions(-)
> create mode 100644 crypto/ecdsa.c
> create mode 100644 crypto/ecdsa_helper.c
> create mode 100644 include/crypto/ecdsa.h
>
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index e240075d6f46..1c5c236b3bbc 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -140,6 +140,13 @@ config CRYPTO_ECDH
> help
> Generic implementation of the ECDH algorithm
>
> +config CRYPTO_ECDSA
> + tristate "ECDSA algorithm"
> + select CRYPTO_AKCIPHER
> + select CRYPTO_ECC
> + help
> + Generic implementation of the ECDSA algorithm
> +
> config CRYPTO_MANAGER
> tristate "Cryptographic algorithm manager"
> select CRYPTO_MANAGER2
> diff --git a/crypto/Makefile b/crypto/Makefile
> index 827740a47a37..9c13eb2ade6a 100644
> --- a/crypto/Makefile
> +++ b/crypto/Makefile
> @@ -38,6 +38,9 @@ obj-$(CONFIG_CRYPTO_ECC) += ecc.o
> ecdh_generic-y := ecdh.o
> ecdh_generic-y += ecdh_helper.o
> obj-$(CONFIG_CRYPTO_ECDH) += ecdh_generic.o
> +ecdsa_generic-y := ecdsa.o
> +ecdsa_generic-y += ecdsa_helper.o
> +obj-$(CONFIG_CRYPTO_ECDSA) += ecdsa_generic.o
>
> $(obj)/rsapubkey-asn1.o: $(obj)/rsapubkey-asn1.c $(obj)/rsapubkey-asn1.h
> $(obj)/rsaprivkey-asn1.o: $(obj)/rsaprivkey-asn1.c $(obj)/rsaprivkey-asn1.h
> diff --git a/crypto/ecdsa.c b/crypto/ecdsa.c
> new file mode 100644
> index ..d415900af3bd
> --- /dev/null
> +++ b/crypto/ecdsa.c
> @@ -0,0 +1,331 @@
> +/*
> + * ECDSA generic algorithm
> + *
> + * Copyright (c) 2017, NVIDIA Corporation. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> Free + * Software Foundation; either version 2 of the License, or (at your
> option) + * any later version.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "ecc.h"
> +
> +struct ecdsa_ctx {
> + unsigned int curve_id;
> + unsigned int ndigits;
> + u64 private_key[ECC_MAX_DIGITS];
> + u64 public_key[2 * ECC_MAX_DIGITS];
> +};
> +
> +static inline struct ecdsa_ctx *ecdsa_get_ctx(struct crypto_akcipher *tfm)
> +{
> + return akcipher_tfm_ctx(tfm);
> +}
> +
> +static void ecdsa_parse_msg_hash(struct akcipher_request *req, u64 *msg,
> + unsigned int ndigits)
> +{
> + unsigned int nbytes = ndigits << ECC_DIGITS_TO_BYTES_SHIFT;
> + unsigned int hash_len, hash_off;
> + unsigned char *hash, *msg_ptr;
> + int i;
> +
> + /*
> + * If hash_len == nbytes:
> + * copy nbytes from req
> + * If hash_len > nbytes:
> + * copy left most nbytes from hash ignoring LSBs
> + * If hash_len < nbytes:
> + * copy hash_len from req and zero remaining bytes
> + * (nbytes - hash_len)
> + */
> + hash_len = req->src[0].length;
> + hash_off = hash_len <= nbytes ? 0 : hash_len - nbytes;
> +
> + msg_ptr = (unsigned char *)msg;
> + hash = sg_virt(&req->src[0]);
> +
> + for (i = hash_off; i < hash_len; i++)
> + *msg_ptr++ = hash[i];
> + for (; i < nbytes; i++)
> + *msg_ptr++ = 0;
> +}
> +
> +int ecdsa_sign(struct akcipher_request *req)
> +{
> + struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
> + struct ecdsa_ctx *ctx = ecdsa_get_ctx(tfm);
> + unsigned int ndigits = ctx->ndigits;
> + unsigned int nbytes = ndigits << ECC_DIGITS_TO_BYTES_SHIFT;
> + unsigned int curve_id = ctx->curve_id;
> + const struct ecc_curve *curve = ecc_get_curve(curve_id);
> + struct ecc_point *x1y1 = NULL;
> + u64 z[ndigits], d[ndigits];
> + u64 k[ndigits], k_inv[ndigits];
> + u64 r[ndigits], s[ndigits];
> + u64 dr[ndigits], zdr[ndigits];
> + u8 *r_ptr, *s_ptr;
> +
> + if (req->dst_len < 2 * nbytes) {
> + req->dst_len = 2 * nbytes;
> + return -EINVAL;
> + }
> +
> + ecdsa_parse_msg_hash(req, z, ndigits);
> +
> + /* d */
> + vli_set(d, (const u64 *)ctx->private_key, ndigits);
> +
> + /* k */
> +#if defined(CONFIG_CRYPTO_MANAGER2)
> + if (req->info) {
> + vli_copy_from_buf(k, ndigits, req->info, nbytes);
Re: [PATCH 5/6] crypto: testmgr: add ECDSA tests
Am Freitag, 20. Januar 2017, 17:06:00 CET schrieb Nitin Kumbhar:
Hi Nitin,
> Update crypto test manager to include NIST ECDSA
> test vectors and various ECDSA tests. These include
> tests for ECDSA signing, ECDSA sign-verification,
> ECDSA signing and verifying generated signatures and
> invalidation of incorrect signatures.
>
> Signed-off-by: Nitin Kumbhar
> ---
> crypto/testmgr.c | 452
> +- crypto/testmgr.h |
> 140 +
> 2 files changed, 589 insertions(+), 3 deletions(-)
>
> diff --git a/crypto/testmgr.c b/crypto/testmgr.c
> index 98eb09782db8..a1db28cbc32d 100644
> --- a/crypto/testmgr.c
> +++ b/crypto/testmgr.c
> @@ -5,6 +5,7 @@
> * Copyright (c) 2002 Jean-Francois Dive
> * Copyright (c) 2007 Nokia Siemens Networks
> * Copyright (c) 2008 Herbert Xu
> + * Copyright (c) 2017 NVIDIA Corporation
> *
> * Updated RFC4106 AES-GCM testing.
> *Authors: Aidan O'Mahony (aidan.o.mah...@intel.com)
> @@ -2085,6 +2086,436 @@ static int alg_test_kpp(const struct alg_test_desc
> *desc, const char *driver, return err;
> }
>
> +static int do_test_ecdsa_verify(struct crypto_akcipher *tfm,
> + struct akcipher_testvec *vec)
> +{
> + struct akcipher_request *req = NULL;
> + u8 *r_str = NULL, *s_str = NULL;
> + u8 *m_str = NULL;
> + struct scatterlist src_tab[3], dst;
> + struct tcrypt_result result;
> + unsigned int outbuf_maxlen;
> + u8 *outbuf = NULL;
> + unsigned int nbytes;
> + int err;
> +
> + /* Alloc akcipher request */
> + req = akcipher_request_alloc(tfm, GFP_KERNEL);
> + if (!req)
> + return -ENOMEM;
> +
> + /* Set private key */
> + err = crypto_akcipher_set_pub_key(tfm, vec->key, vec->key_len);
> + if (err)
> + goto error;
> +
> + /*
> + * vec->c always contains k, R and S in that order. All are
> + * of same size and are equal to n i.e. the order of
> + * an elliptic curve.
> + */
> + nbytes = vec->c_size / 3;
> +
> + r_str = kzalloc(nbytes, GFP_KERNEL);
> + s_str = kzalloc(nbytes, GFP_KERNEL);
> + m_str = kzalloc(vec->m_size, GFP_KERNEL);
> + if (!r_str || !s_str || !m_str) {
> + err = -ENOMEM;
> + goto error;
> + }
> + memcpy(r_str, (u8 *)vec->c + nbytes, nbytes);
> + memcpy(s_str, (u8 *)vec->c + 2 * nbytes, nbytes);
> + memcpy(m_str, vec->m, vec->m_size);
> +
> + outbuf_maxlen = crypto_akcipher_maxsize(tfm);
> + if (outbuf_maxlen < 0) {
> + err = outbuf_maxlen;
> + goto error;
> + }
> + outbuf = kzalloc(outbuf_maxlen, GFP_KERNEL);
> + if (!outbuf) {
> + err = -ENOMEM;
> + goto error;
> + }
> +
> + /* Set src and dst buffers */
> + sg_init_table(src_tab, 3);
> + sg_set_buf(&src_tab[0], m_str, vec->m_size);
> + sg_set_buf(&src_tab[1], r_str, nbytes);
> + sg_set_buf(&src_tab[2], s_str, nbytes);
> + sg_init_one(&dst, outbuf, outbuf_maxlen);
> +
> + akcipher_request_set_crypt(req, src_tab, &dst,
> +vec->m_size + 2 * nbytes, outbuf_maxlen);
> +
> + /* Set up result callback */
> + init_completion(&result.completion);
> + akcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
> + tcrypt_complete, &result);
> +
> + /* Run ecdsa verify operation on sig (r,s) */
> + err = wait_async_op(&result, crypto_akcipher_verify(req));
> + if (err) {
> + pr_err("alg: ecdsa: verify(rs) test failed. err %d\n", err);
> + goto error;
> + }
> +error:
> + akcipher_request_free(req);
> + kfree(r_str);
> + kfree(s_str);
> + kfree(m_str);
> + kfree(outbuf);
> + return err;
> +}
> +
> +static int do_test_ecdsa_invalid_verify(struct crypto_akcipher *tfm,
> + struct akcipher_testvec *vec)
> +{
> + struct akcipher_request *req = NULL;
> + u8 *r_str = NULL, *s_str = NULL;
> + u8 *m_str = NULL;
> + struct scatterlist src_tab[3], dst;
> + struct tcrypt_result result;
> + unsigned int outbuf_maxlen;
> + u8 *outbuf = NULL;
> + unsigned int nbytes;
> + int err;
> +
> + /* Alloc akcipher request */
> + req = akcipher_request_alloc(tfm, GFP_KERNEL);
> + if (!req)
> + return -ENOMEM;
> +
> + /* Set private key */
> + err = crypto_akcipher_set_pub_key(tfm, vec->key, vec->key_len);
> + if (err)
> + goto error;
> +
> + /*
> + * vec->c always contains k, R and S in that order. All are
> + * of same size and are equal to n i.e. the order of
> + * an elliptic curve.
> + */
> + nbytes = vec->c_size / 3;
> +
> + r_str = kzalloc(nbytes, GFP_KERNEL);
> + s_str = kzalloc(nbytes, GFP_KERNEL);
> + m_str = kzalloc(vec->m_size, GFP_KERNEL);
> + if (!r_str || !s_str || !m_str) {
Re: [PATCH 0/2] Introduce AMD Secure Processor device
On 01/20/2017 02:45 AM, Greg KH wrote: On Thu, Jan 19, 2017 at 02:03:12PM -0600, Brijesh Singh wrote: Hi Greg, On 01/19/2017 12:21 PM, Greg KH wrote: On Thu, Jan 19, 2017 at 01:07:50PM -0500, Brijesh Singh wrote: The CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor, which is not dedicated solely to crypto. The AMD Secure Processor includes CCP and PSP (Platform Secure Processor) devices. This patch series moves the CCP device driver to the misc directory and creates a framework that allows functional component of the AMD Secure Processor to be initialized and handled appropriately. Why the misc directory? I don't see the justification here... Since this driver is not solely for crypto purposes and do not fit in any of the standard categories hence I thought of moving it into misc directory. I am open to other suggestions unless Herbert is ok with leaving it into crypto and allowing the addition of the Secure Processor support. The patch series allows the CCP driver to support other Secure Processor functions, e.g Secure Encrypted Virtualization (SEV) key management. In past, I tried to add SEV support into existing CCP driver [1] but we quickly learned that CCP driver should be moved outside the crypto directory otherwise will end up adding non crypto code into drivers/crypto directory. Once this cleanup is accepted then I can work to add SEV support inside the CCP driver. [1] http://marc.info/?l=linux-kernel&m=147204118426151&w=2 Ok, what type of interface will this driver have with userspace and/or other parts of the kernel? Is there a misc char device burried in there somewhere (I couldn't find it in the big diff sent out), or is this driver just creating specific apis that other parts of the kernel will call if available? Eventually, the driver will export functions which will be used by KVM to encrypt the guest memory and more. Additionally, If SEV device is detected then driver will create a misc char device which can be used by userspace to import/export certificates etc. I do realize that we need to get some more context on why this refactoring is needed and how it will benefit the SEV device integration. I will drop this patch for now, will include it as part of next SEV RFC patch series (which provides the complete context with examples). thanks, ~ Brijesh I think we need to see more code here, broken up into sane and reviewable pieces, before we could either say "No don't do that!" or "sure, let me go merge these!" :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] misc: amd-sp: introduce the AMD Secure Processor device
Hi Brijesh, [auto build test WARNING on cryptodev/master] [also build test WARNING on next-20170120] [cannot apply to char-misc/char-misc-testing v4.10-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Brijesh-Singh/Introduce-AMD-Secure-Processor-device/20170120-185157 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master config: xtensa-allmodconfig (attached as .config) compiler: xtensa-linux-gcc (GCC) 4.9.0 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=xtensa All warnings (new ones prefixed by >>): warning: (CRYPTO_DEV_CCP_CRYPTO) selects AMD_SP which has unmet direct dependencies ((X86 && PCI || ARM64 && (OF_ADDRESS || ACPI)) && HAS_IOMEM) --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 1/2] crypto: move CCP device driver to misc
Hi Brijesh, [auto build test ERROR on cryptodev/master] [also build test ERROR on next-20170120] [cannot apply to char-misc/char-misc-testing v4.10-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Brijesh-Singh/Introduce-AMD-Secure-Processor-device/20170120-185157 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master config: um-allyesconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=um All errors (new ones prefixed by >>): arch/um/drivers/built-in.o: In function `vde_open_real': (.text+0xc9a1): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `vde_open_real': (.text+0xc7ec): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `vde_open_real': (.text+0xcb05): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `pcap_nametoaddr': (.text+0x1d595): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `pcap_nametonetaddr': (.text+0x1d635): warning: Using 'getnetbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `pcap_nametoproto': (.text+0x1d855): warning: Using 'getprotobyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `pcap_nametoport': (.text+0x1d687): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking drivers/built-in.o: In function `ccp_init_dm_workarea': >> drivers/misc/amd-sp/ccp-ops.c:141: undefined reference to `dma_pool_alloc' drivers/built-in.o: In function `ccp_init_dm_workarea': include/linux/dma-mapping.h:190: undefined reference to `bad_dma_ops' drivers/built-in.o: In function `ccp_sg_free': include/linux/dma-mapping.h:242: undefined reference to `bad_dma_ops' drivers/built-in.o: In function `ccp_dm_free': >> drivers/misc/amd-sp/ccp-ops.c:112: undefined reference to `dma_pool_free' drivers/built-in.o: In function `ccp_dm_free': include/linux/dma-mapping.h:207: undefined reference to `bad_dma_ops' drivers/built-in.o: In function `ccp_init_data': include/linux/dma-mapping.h:227: undefined reference to `bad_dma_ops' drivers/built-in.o: In function `ccp_destroy': >> drivers/misc/amd-sp/ccp-dev-v3.c:501: undefined reference to >> `dma_pool_destroy' drivers/built-in.o: In function `ccp_init': >> drivers/misc/amd-sp/ccp-dev-v3.c:337: undefined reference to >> `dma_pool_create' drivers/misc/amd-sp/ccp-dev-v3.c:456: undefined reference to `dma_pool_destroy' drivers/built-in.o: In function `ccp5_destroy': include/linux/dma-mapping.h:484: undefined reference to `bad_dma_ops' include/linux/dma-mapping.h:490: undefined reference to `bad_dma_ops' drivers/built-in.o: In function `ccp5_init': >> drivers/misc/amd-sp/ccp-dev-v5.c:676: undefined reference to >> `dma_pool_create' drivers/built-in.o: In function `ccp5_init': include/linux/dma-mapping.h:463: undefined reference to `bad_dma_ops' drivers/built-in.o: In function `ccp5_init': >> drivers/misc/amd-sp/ccp-dev-v5.c:861: undefined reference to >> `dma_pool_destroy' drivers/built-in.o: In function `ccp_platform_probe': drivers/misc/amd-sp/ccp-platform.c:148: undefined reference to `devm_ioremap_resource' drivers/built-in.o: In function `ccp_platform_probe': include/linux/dma-mapping.h:555: undefined reference to `bad_dma_ops' include/linux/dma-mapping.h:542: undefined reference to `bad_dma_ops' include/linux/dma-mapping.h:544: undefined reference to `bad_dma_ops' include/linux/dma-mapping.h:542: undefined reference to `bad_dma_ops' include/linux/dma-mapping.h:544: undefined reference to `bad_dma_ops' drivers/built-in.o: In function `ccp_cmd_callback': drivers/misc/amd-sp/ccp-d
Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers
Hi all, Le 13/01/2017 à 12:39, Herbert Xu a écrit : > On Fri, Jan 13, 2017 at 12:36:56PM +0100, Stephan Müller wrote: >> >> I thought I understood that you would not want to see it in any >> implementation. But, ok, if you want to leave it. > > If you remove it from authenc then authenc will be broken. > Hence if the copy of the associated data is needed in the crypto/authenc.c driver, then I should also keep this copy in the drivers/crypto/atmel-aes.c for authenc(hmac(shaX),cbc-aes) algorithms [1], shouldn't I? If so, should I keep the current not optimized implementation of atmel_aes_authenc_copy_assoc() or try to use the code extracted by Stephan from crypto/authenc.c using the null cipher as proposed in this thread? As said earlier in this thread, copying the associated data is not a so big deal when compared to the main crypto processing. For instance, with IPSec ESP with AES in CBC mode, the associated data layout should be: Security Parameters Index (SPI): 4 bytes Sequence Number: 4 bytes AES IV: 16 bytes So it's only a 24 byte copy. I've taken Stephan's other comments into account from his review of the atmel-authenc driver so I'm preparing a new series but I don't know what to do for the associated data copy. Please let me know what you recommend, thanks! Best regards, Cyrille [1] https://lkml.org/lkml/2016/12/22/306 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Introduce AMD Secure Processor device
On Fri, Jan 20, 2017 at 09:40:49AM -0600, Brijesh Singh wrote: > > On 01/20/2017 02:45 AM, Greg KH wrote: > > On Thu, Jan 19, 2017 at 02:03:12PM -0600, Brijesh Singh wrote: > > > Hi Greg, > > > > > > On 01/19/2017 12:21 PM, Greg KH wrote: > > > > On Thu, Jan 19, 2017 at 01:07:50PM -0500, Brijesh Singh wrote: > > > > > The CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure > > > > > Processor, > > > > > which is not dedicated solely to crypto. The AMD Secure Processor > > > > > includes > > > > > CCP and PSP (Platform Secure Processor) devices. > > > > > > > > > > This patch series moves the CCP device driver to the misc directory > > > > > and > > > > > creates a framework that allows functional component of the AMD Secure > > > > > Processor to be initialized and handled appropriately. > > > > > > > > Why the misc directory? I don't see the justification here... > > > > > > > > > > Since this driver is not solely for crypto purposes and do not fit in any > > > of > > > the standard categories hence I thought of moving it into misc directory. > > > I > > > am open to other suggestions unless Herbert is ok with leaving it into > > > crypto and allowing the addition of the Secure Processor support. > > > > > > The patch series allows the CCP driver to support other Secure Processor > > > functions, e.g Secure Encrypted Virtualization (SEV) key management. In > > > past, I tried to add SEV support into existing CCP driver [1] but we > > > quickly > > > learned that CCP driver should be moved outside the crypto directory > > > otherwise will end up adding non crypto code into drivers/crypto > > > directory. > > > Once this cleanup is accepted then I can work to add SEV support inside > > > the > > > CCP driver. > > > > > > [1] http://marc.info/?l=linux-kernel&m=147204118426151&w=2 > > > > Ok, what type of interface will this driver have with userspace and/or > > other parts of the kernel? Is there a misc char device burried in there > > somewhere (I couldn't find it in the big diff sent out), or is this > > driver just creating specific apis that other parts of the kernel will > > call if available? > > > > Eventually, the driver will export functions which will be used by KVM > to encrypt the guest memory and more. Additionally, If SEV device is > detected then driver will create a misc char device which can be used by > userspace to import/export certificates etc. Why create a new api for certificates, why not just use the existing kernel key handling for it? Having a random char device for something like this is going to be rough to approve, I'll wait for the patches before I start objecting really hard :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] misc: amd-sp: introduce the AMD Secure Processor device
Hi Brijesh, [auto build test ERROR on cryptodev/master] [also build test ERROR on next-20170120] [cannot apply to char-misc/char-misc-testing v4.10-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Brijesh-Singh/Introduce-AMD-Secure-Processor-device/20170120-185157 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master config: um-allyesconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=um All error/warnings (new ones prefixed by >>): warning: (AMD_CCP && SND_SOC_SH4_SIU) selects DMADEVICES which has unmet direct dependencies (HAS_DMA) arch/um/drivers/built-in.o: In function `vde_open_real': (.text+0xc9a1): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `vde_open_real': (.text+0xc7ec): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `vde_open_real': (.text+0xcb05): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `pcap_nametoaddr': (.text+0x1d595): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `pcap_nametonetaddr': (.text+0x1d635): warning: Using 'getnetbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `pcap_nametoproto': (.text+0x1d855): warning: Using 'getprotobyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/built-in.o: In function `pcap_nametoport': (.text+0x1d687): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking crypto/built-in.o: In function `async_memcpy': include/linux/dma-mapping.h:257: undefined reference to `bad_dma_ops' include/linux/dma-mapping.h:257: undefined reference to `bad_dma_ops' crypto/built-in.o: In function `async_xor': include/linux/dma-mapping.h:257: undefined reference to `bad_dma_ops' include/linux/dma-mapping.h:257: undefined reference to `bad_dma_ops' crypto/built-in.o: In function `async_xor_val': include/linux/dma-mapping.h:257: undefined reference to `bad_dma_ops' crypto/built-in.o:include/linux/dma-mapping.h:257: more undefined references to `bad_dma_ops' follow drivers/built-in.o: In function `dwc_desc_get': >> include/linux/dmapool.h:30: undefined reference to `dma_pool_alloc' drivers/built-in.o: In function `dwc_desc_put': >> drivers/dma/dw/core.c:137: undefined reference to `dma_pool_free' drivers/dma/dw/core.c:133: undefined reference to `dma_pool_free' drivers/built-in.o: In function `dw_dma_probe': >> drivers/dma/dw/core.c:1508: undefined reference to `dmam_pool_create' drivers/built-in.o: In function `dw_probe': >> drivers/dma/dw/platform.c:192: undefined reference to `devm_ioremap_resource' drivers/built-in.o: In function `dw_probe': include/linux/dma-mapping.h:555: undefined reference to `bad_dma_ops' include/linux/dma-mapping.h:542: undefined reference to `bad_dma_ops' include/linux/dma-mapping.h:544: undefined reference to `bad_dma_ops' include/linux/dma-mapping.h:542: undefined reference to `bad_dma_ops' include/linux/dma-mapping.h:544: undefined reference to `bad_dma_ops' drivers/built-in.o: In function `fsl_edma_free_desc': >> drivers/dma/fsl-edma.c:288: undefined reference to `dma_pool_free' drivers/built-in.o: In function `fsl_edma_alloc_desc': >> drivers/dma/fsl-edma.c:525: undefined reference to `dma_pool_alloc' drivers/dma/fsl-edma.c:525: undefined reference to `dma_pool_free' drivers/built-in.o: In function `fsl_edma_free_chan_resources': >> drivers/dma/fsl-edma.c:808: undefined reference to `dma_pool_destroy' drivers/built-in.o: In function `fsl_edma_alloc_chan_resources': >> drivers/dma/fsl-edma.c:788: undefined reference to `dma_pool_create' drivers/built-in.o: In function `fsl_edma_probe': >> drivers/
Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers
Am Freitag, 20. Januar 2017, 18:07:04 CET schrieb Cyrille Pitchen: Hi Cyrille, > > I've taken Stephan's other comments into account from his review of the > atmel-authenc driver so I'm preparing a new series but I don't know what to > do for the associated data copy. > > Please let me know what you recommend, thanks! The question is where the null context shall be saved. As Herbert mentioned, he may not want to have it in crypto_aead. Herbert, as this implementation also requires the copy, shall we leave the null context in crypto_aead? If so, Cyrille can simply use patch 01 from this series and apply the change to his code similar to what I did in patches 02 - 13. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
