mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
* [ptxdist] [RFC/PATCH 0/3] cryptodev
@ 2017-06-24 13:47 Ladislav Michl
  2017-06-24 13:48 ` [ptxdist] [PATCH 1/3] cryptodev: new package Ladislav Michl
                   ` (3 more replies)
  0 siblings, 4 replies; 13+ messages in thread
From: Ladislav Michl @ 2017-06-24 13:47 UTC (permalink / raw)
  To: ptxdist

Hi there!

This serie adds support for cryptodev hardware acceleration.
However, there's one issue unresolved: cryptodev module
loading.
As we have three different modutils implementations available
and also supporting systemd and sysv init it is a bit messy
to generate proper config to load cryptodev at boot time.
So we could either leave module loading to BSP or do something
on ptxdist level. Thoughts?

Thank you,
	ladis

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [ptxdist] [PATCH 1/3] cryptodev: new package
  2017-06-24 13:47 [ptxdist] [RFC/PATCH 0/3] cryptodev Ladislav Michl
@ 2017-06-24 13:48 ` Ladislav Michl
  2017-06-24 13:49 ` [ptxdist] [PATCH 2/3] openssl: add cryptodev support Ladislav Michl
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 13+ messages in thread
From: Ladislav Michl @ 2017-06-24 13:48 UTC (permalink / raw)
  To: ptxdist

Cryptodev-linux is a device that allows access to Linux kernel
cryptographic drivers; thus allowing of userspace applications
to take advantage of hardware accelerators. Cryptodev-linux is
implemented as a standalone module that requires no dependencies
other than a stock linux kernel. Its API is compatible with
OpenBSD's cryptodev userspace API (/dev/crypto).

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 rules/cryptodev.in   | 11 ++++++++
 rules/cryptodev.make | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 86 insertions(+)

diff --git a/rules/cryptodev.in b/rules/cryptodev.in
new file mode 100644
index 000000000..7a231340e
--- /dev/null
+++ b/rules/cryptodev.in
@@ -0,0 +1,11 @@
+## SECTION=core
+
+config CRYPTODEV
+	tristate
+	select KERNEL
+	prompt "cryptodev"
+	help
+	  Cryptodev-linux is a device that allows access to Linux kernel
+	  cryptographic drivers; thus allowing of userspace applications
+	  to take advantage of hardware accelerators. Its API is
+	  compatible with OpenBSD's cryptodev userspace API (/dev/crypto). 
diff --git a/rules/cryptodev.make b/rules/cryptodev.make
new file mode 100644
index 000000000..0cad936b3
--- /dev/null
+++ b/rules/cryptodev.make
@@ -0,0 +1,75 @@
+# -*-makefile-*-
+#
+# Copyright (C) 2017 by Ladislav Michl <ladis@linux-mips.org>
+#
+# See CREDITS for details about who has contributed to this project.
+#
+# For further information about the PTXdist project and license conditions
+# see the README file.
+#
+
+#
+# We provide this package
+#
+PACKAGES-$(PTXCONF_CRYPTODEV) += cryptodev
+
+#
+# Paths and names and versions
+#
+CRYPTODEV_VERSION	:= 1.9
+CRYPTODEV_MD5		:= cb4e0ed9e5937716c7c8a7be84895b6d
+CRYPTODEV		:= cryptodev-linux-$(CRYPTODEV_VERSION)
+CRYPTODEV_SUFFIX	:= tar.gz
+CRYPTODEV_URL		:= \
+	http://nwl.cc/pub/cryptodev-linux/$(CRYPTODEV).$(CRYPTODEV_SUFFIX) \
+	http://download.gna.org/cryptodev-linux/$(CRYPTODEV).$(CRYPTODEV_SUFFIX)
+CRYPTODEV_SOURCE	:= $(SRCDIR)/$(CRYPTODEV).$(CRYPTODEV_SUFFIX)
+CRYPTODEV_DIR		:= $(BUILDDIR)/$(CRYPTODEV)
+CRYPTODEV_LICENSE	:= GPL-2.0
+
+ifdef PTXCONF_CRYPTODEV
+$(STATEDIR)/kernel.targetinstall.post: $(STATEDIR)/cryptodev.targetinstall
+endif
+
+# ----------------------------------------------------------------------------
+# Prepare
+# ----------------------------------------------------------------------------
+
+$(STATEDIR)/cryptodev.prepare:
+	@$(call targetinfo)
+	@$(call touch)
+
+# ----------------------------------------------------------------------------
+# Compile
+# ----------------------------------------------------------------------------
+
+$(STATEDIR)/cryptodev.compile:
+	@$(call targetinfo)
+	$(KERNEL_PATH) $(KERNEL_ENV) $(MAKE) $(KERNEL_MAKEVARS) \
+		KERNEL_DIR=$(KERNEL_DIR) \
+		-C $(CRYPTODEV_DIR)
+	@$(call touch)
+
+# ----------------------------------------------------------------------------
+# Install
+# ----------------------------------------------------------------------------
+
+$(STATEDIR)/cryptodev.install:
+	@$(call targetinfo)
+	@$(call touch)
+
+# ----------------------------------------------------------------------------
+# Target-Install
+# ----------------------------------------------------------------------------
+
+$(STATEDIR)/cryptodev.targetinstall:
+	@$(call targetinfo)
+	$(KERNEL_PATH) $(KERNEL_ENV) $(MAKE) $(KERNEL_MAKEVARS) \
+		KERNEL_DIR=$(KERNEL_DIR) \
+		DESTDIR=$(SYSROOT) \
+		prefix=/usr \
+		-C $(CRYPTODEV_DIR) \
+		install
+	@$(call touch)
+
+# vim: syntax=make
-- 
2.11.0


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [ptxdist] [PATCH 2/3] openssl: add cryptodev support
  2017-06-24 13:47 [ptxdist] [RFC/PATCH 0/3] cryptodev Ladislav Michl
  2017-06-24 13:48 ` [ptxdist] [PATCH 1/3] cryptodev: new package Ladislav Michl
@ 2017-06-24 13:49 ` Ladislav Michl
  2017-06-24 13:49 ` [ptxdist] [PATCH 3/3] gnutls: " Ladislav Michl
  2017-06-30 14:36 ` [ptxdist] [RFC/PATCH 0/3] cryptodev Michael Olbrich
  3 siblings, 0 replies; 13+ messages in thread
From: Ladislav Michl @ 2017-06-24 13:49 UTC (permalink / raw)
  To: ptxdist

For OpenSSL_1_0_2-stable branch two patches mentioned in cryptodev's
README were forward-ported. That's safe to do as they are no-op
until cryptodev support is enabled. These patches were also merged
to master branch in 2014 to be finally removed altogether
in commit f39a5501ce69cab0c7282f5dcbf2b80d8ee259f2 as a part of
openssl's effort to move to Apache License version 2.0.
See this PR: https://github.com/openssl/openssl/pull/3699
Blog post mentioned in said PR also states: "...but we expect to have
a replacement soon (for at least Linux and FreeBSD)." Whatever "soon"
means...

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 ...todev-Fix-issue-with-signature-generation.patch | 404 +++++++++++++++++++++
 ...0201-cryptodev-allow-copying-EVP-contexts.patch | 205 +++++++++++
 patches/openssl-1.0.2l/series                      |   3 +
 rules/openssl.in                                   |  16 +
 rules/openssl.make                                 |   7 +
 5 files changed, 635 insertions(+)

diff --git a/patches/openssl-1.0.2l/0200-cryptodev-Fix-issue-with-signature-generation.patch b/patches/openssl-1.0.2l/0200-cryptodev-Fix-issue-with-signature-generation.patch
new file mode 100644
index 000000000..6e660b3d3
--- /dev/null
+++ b/patches/openssl-1.0.2l/0200-cryptodev-Fix-issue-with-signature-generation.patch
@@ -0,0 +1,404 @@
+From 63334c3d1c3919b046a7926a131e676ce2705fb5 Mon Sep 17 00:00:00 2001
+From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
+Date: Fri, 4 Jul 2014 07:31:25 +0200
+Subject: [PATCH 1/2] cryptodev: Fix issue with signature generation
+
+That patch also enables support for SHA2 hashes, and
+removes support for hashes that were never supported by
+cryptodev.
+
+[manually rebased to OpenSSL_1_0_2-stable branch]
+Ladislav Michl <ladis@linux-mips.org>
+---
+ crypto/engine/eng_cryptodev.c | 181 ++++++++++++++++++++++++++++++++----------
+ 1 file changed, 141 insertions(+), 40 deletions(-)
+
+diff --git a/crypto/engine/eng_cryptodev.c b/crypto/engine/eng_cryptodev.c
+index af59471c4..75bb85b26 100644
+--- a/crypto/engine/eng_cryptodev.c
++++ b/crypto/engine/eng_cryptodev.c
+@@ -2,6 +2,7 @@
+  * Copyright (c) 2002 Bob Beck <beck@openbsd.org>
+  * Copyright (c) 2002 Theo de Raadt
+  * Copyright (c) 2002 Markus Friedl
++ * Copyright (c) 2012 Nikos Mavrogiannopoulos
+  * All rights reserved.
+  *
+  * Redistribution and use in source and binary forms, with or without
+@@ -73,7 +74,6 @@ struct dev_crypto_state {
+     struct session_op d_sess;
+     int d_fd;
+ # ifdef USE_CRYPTODEV_DIGESTS
+-    char dummy_mac_key[HASH_MAX_LEN];
+     unsigned char digest_res[HASH_MAX_LEN];
+     char *mac_data;
+     int mac_len;
+@@ -190,8 +190,10 @@ static struct {
+ static struct {
+     int id;
+     int nid;
+-    int keylen;
++    int digestlen;
+ } digests[] = {
++#if 0
++    /* HMAC is not supported */
+     {
+         CRYPTO_MD5_HMAC, NID_hmacWithMD5, 16
+     },
+@@ -208,6 +210,7 @@ static struct {
+     {
+         CRYPTO_SHA1_KPDK, NID_undef, 0
+     },
++#endif
+     {
+         CRYPTO_MD5, NID_md5, 16
+     },
+@@ -215,6 +218,15 @@ static struct {
+         CRYPTO_SHA1, NID_sha1, 20
+     },
+     {
++        CRYPTO_SHA2_256, NID_sha256, 32
++    },
++    {
++        CRYPTO_SHA2_384, NID_sha384, 48
++    },
++    {
++        CRYPTO_SHA2_512, NID_sha512, 64
++    },
++    {
+         0, NID_undef, 0
+     },
+ };
+@@ -287,6 +299,7 @@ static int get_asym_dev_crypto(void)
+ static int get_cryptodev_ciphers(const int **cnids)
+ {
+     static int nids[CRYPTO_ALGORITHM_MAX];
++    unsigned char fake_key[CRYPTO_CIPHER_MAX_KEY_LEN];
+     struct session_op sess;
+     int fd, i, count = 0;
+ 
+@@ -295,7 +308,7 @@ static int get_cryptodev_ciphers(const int **cnids)
+         return (0);
+     }
+     memset(&sess, 0, sizeof(sess));
+-    sess.key = (caddr_t) "123456789abcdefghijklmno";
++    sess.key = (void*) fake_key;
+ 
+     for (i = 0; ciphers[i].id && count < CRYPTO_ALGORITHM_MAX; i++) {
+         if (ciphers[i].nid == NID_undef)
+@@ -326,6 +339,7 @@ static int get_cryptodev_ciphers(const int **cnids)
+ static int get_cryptodev_digests(const int **cnids)
+ {
+     static int nids[CRYPTO_ALGORITHM_MAX];
++    unsigned char fake_key[CRYPTO_CIPHER_MAX_KEY_LEN];
+     struct session_op sess;
+     int fd, i, count = 0;
+ 
+@@ -334,12 +348,12 @@ static int get_cryptodev_digests(const int **cnids)
+         return (0);
+     }
+     memset(&sess, 0, sizeof(sess));
+-    sess.mackey = (caddr_t) "123456789abcdefghijklmno";
++    sess.mackey = fake_key;
+     for (i = 0; digests[i].id && count < CRYPTO_ALGORITHM_MAX; i++) {
+         if (digests[i].nid == NID_undef)
+             continue;
+         sess.mac = digests[i].id;
+-        sess.mackeylen = digests[i].keylen;
++        sess.mackeylen = 8;
+         sess.cipher = 0;
+         if (ioctl(fd, CIOCGSESSION, &sess) != -1 &&
+             ioctl(fd, CIOCFSESSION, &sess.ses) != -1)
+@@ -425,14 +439,14 @@ cryptodev_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out,
+     cryp.ses = sess->ses;
+     cryp.flags = 0;
+     cryp.len = inl;
+-    cryp.src = (caddr_t) in;
+-    cryp.dst = (caddr_t) out;
++    cryp.src = (void*) in;
++    cryp.dst = (void*) out;
+     cryp.mac = 0;
+ 
+     cryp.op = ctx->encrypt ? COP_ENCRYPT : COP_DECRYPT;
+ 
+     if (ctx->cipher->iv_len) {
+-        cryp.iv = (caddr_t) ctx->iv;
++        cryp.iv = (void*) ctx->iv;
+         if (!ctx->encrypt) {
+             iiv = in + inl - ctx->cipher->iv_len;
+             memcpy(save_iv, iiv, ctx->cipher->iv_len);
+@@ -484,7 +498,7 @@ cryptodev_init_key(EVP_CIPHER_CTX *ctx, const unsigned char *key,
+     if ((state->d_fd = get_dev_crypto()) < 0)
+         return (0);
+ 
+-    sess->key = (caddr_t) key;
++    sess->key = (void*) key;
+     sess->keylen = ctx->key_len;
+     sess->cipher = cipher;
+ 
+@@ -750,16 +764,6 @@ static int digest_nid_to_cryptodev(int nid)
+     return (0);
+ }
+ 
+-static int digest_key_length(int nid)
+-{
+-    int i;
+-
+-    for (i = 0; digests[i].id; i++)
+-        if (digests[i].nid == nid)
+-            return digests[i].keylen;
+-    return (0);
+-}
+-
+ static int cryptodev_digest_init(EVP_MD_CTX *ctx)
+ {
+     struct dev_crypto_state *state = ctx->md_data;
+@@ -778,8 +782,8 @@ static int cryptodev_digest_init(EVP_MD_CTX *ctx)
+         return (0);
+     }
+ 
+-    sess->mackey = state->dummy_mac_key;
+-    sess->mackeylen = digest_key_length(ctx->digest->type);
++    sess->mackey = NULL;
++    sess->mackeylen = 0;
+     sess->mac = digest;
+ 
+     if (ioctl(state->d_fd, CIOCGSESSION, sess) < 0) {
+@@ -805,7 +809,7 @@ static int cryptodev_digest_update(EVP_MD_CTX *ctx, const void *data,
+     }
+ 
+     if (!count) {
+-        return (0);
++        return (1);
+     }
+ 
+     if (!(ctx->flags & EVP_MD_CTX_FLAG_ONESHOT)) {
+@@ -830,9 +834,9 @@ static int cryptodev_digest_update(EVP_MD_CTX *ctx, const void *data,
+     cryp.ses = sess->ses;
+     cryp.flags = 0;
+     cryp.len = count;
+-    cryp.src = (caddr_t) data;
++    cryp.src = (void*) data;
+     cryp.dst = NULL;
+-    cryp.mac = (caddr_t) state->digest_res;
++    cryp.mac = (void*) state->digest_res;
+     if (ioctl(state->d_fd, CIOCCRYPT, &cryp) < 0) {
+         printf("cryptodev_digest_update: digest failed\n");
+         return (0);
+@@ -861,7 +865,7 @@ static int cryptodev_digest_final(EVP_MD_CTX *ctx, unsigned char *md)
+         cryp.len = state->mac_len;
+         cryp.src = state->mac_data;
+         cryp.dst = NULL;
+-        cryp.mac = (caddr_t) md;
++        cryp.mac = (void*) md;
+         if (ioctl(state->d_fd, CIOCCRYPT, &cryp) < 0) {
+             printf("cryptodev_digest_final: digest failed\n");
+             return (0);
+@@ -923,8 +927,8 @@ static int cryptodev_digest_copy(EVP_MD_CTX *to, const EVP_MD_CTX *from)
+ 
+     digest = digest_nid_to_cryptodev(to->digest->type);
+ 
+-    sess->mackey = dstate->dummy_mac_key;
+-    sess->mackeylen = digest_key_length(to->digest->type);
++    sess->mackey = NULL;
++    sess->mackeylen = 0;
+     sess->mac = digest;
+ 
+     dstate->d_fd = get_dev_crypto();
+@@ -951,34 +955,118 @@ static int cryptodev_digest_copy(EVP_MD_CTX *to, const EVP_MD_CTX *from)
+     return 1;
+ }
+ 
+-const EVP_MD cryptodev_sha1 = {
++static const EVP_MD cryptodev_sha1 = {
+     NID_sha1,
+-    NID_undef,
++    NID_sha1WithRSAEncryption,
+     SHA_DIGEST_LENGTH,
++#if defined(EVP_MD_FLAG_PKEY_METHOD_SIGNATURE) && defined(EVP_MD_FLAG_DIGALGID_ABSENT)
++    EVP_MD_FLAG_PKEY_METHOD_SIGNATURE |
++    EVP_MD_FLAG_DIGALGID_ABSENT |
++#endif
+     EVP_MD_FLAG_ONESHOT,
+     cryptodev_digest_init,
+     cryptodev_digest_update,
+     cryptodev_digest_final,
+     cryptodev_digest_copy,
+     cryptodev_digest_cleanup,
+-    EVP_PKEY_NULL_method,
++    EVP_PKEY_RSA_method,
+     SHA_CBLOCK,
+-    sizeof(struct dev_crypto_state),
++    sizeof(EVP_MD *) + sizeof(struct dev_crypto_state),
++};
++
++static const EVP_MD cryptodev_sha256 = {
++    NID_sha256,
++    NID_sha256WithRSAEncryption,
++    SHA256_DIGEST_LENGTH,
++#if defined(EVP_MD_FLAG_PKEY_METHOD_SIGNATURE) && defined(EVP_MD_FLAG_DIGALGID_ABSENT)
++    EVP_MD_FLAG_PKEY_METHOD_SIGNATURE |
++    EVP_MD_FLAG_DIGALGID_ABSENT |
++#endif
++    EVP_MD_FLAG_ONESHOT,
++    cryptodev_digest_init,
++    cryptodev_digest_update,
++    cryptodev_digest_final,
++    cryptodev_digest_copy,
++    cryptodev_digest_cleanup,
++    EVP_PKEY_RSA_method,
++    SHA256_CBLOCK,
++    sizeof(EVP_MD *) + sizeof(struct dev_crypto_state),
++};
++
++static const EVP_MD cryptodev_sha224 = {
++    NID_sha224,
++    NID_sha224WithRSAEncryption,
++    SHA224_DIGEST_LENGTH,
++#if defined(EVP_MD_FLAG_PKEY_METHOD_SIGNATURE) && defined(EVP_MD_FLAG_DIGALGID_ABSENT)
++    EVP_MD_FLAG_PKEY_METHOD_SIGNATURE |
++    EVP_MD_FLAG_DIGALGID_ABSENT |
++#endif
++    EVP_MD_FLAG_ONESHOT,
++    cryptodev_digest_init,
++    cryptodev_digest_update,
++    cryptodev_digest_final,
++    cryptodev_digest_copy,
++    cryptodev_digest_cleanup,
++    EVP_PKEY_RSA_method,
++    SHA256_CBLOCK,
++    sizeof(EVP_MD *) + sizeof(struct dev_crypto_state),
++};
++
++static const EVP_MD cryptodev_sha384 = {
++    NID_sha384,
++    NID_sha384WithRSAEncryption,
++    SHA384_DIGEST_LENGTH,
++#if defined(EVP_MD_FLAG_PKEY_METHOD_SIGNATURE) && defined(EVP_MD_FLAG_DIGALGID_ABSENT)
++    EVP_MD_FLAG_PKEY_METHOD_SIGNATURE |
++    EVP_MD_FLAG_DIGALGID_ABSENT |
++#endif
++    EVP_MD_FLAG_ONESHOT,
++    cryptodev_digest_init,
++    cryptodev_digest_update,
++    cryptodev_digest_final,
++    cryptodev_digest_copy,
++    cryptodev_digest_cleanup,
++    EVP_PKEY_RSA_method,
++    SHA512_CBLOCK,
++    sizeof(EVP_MD *) + sizeof(struct dev_crypto_state),
++};
++
++static const EVP_MD cryptodev_sha512 = {
++    NID_sha512,
++    NID_sha512WithRSAEncryption,
++    SHA512_DIGEST_LENGTH,
++#if defined(EVP_MD_FLAG_PKEY_METHOD_SIGNATURE) && defined(EVP_MD_FLAG_DIGALGID_ABSENT)
++    EVP_MD_FLAG_PKEY_METHOD_SIGNATURE |
++    EVP_MD_FLAG_DIGALGID_ABSENT |
++#endif
++    EVP_MD_FLAG_ONESHOT,
++    cryptodev_digest_init,
++    cryptodev_digest_update,
++    cryptodev_digest_final,
++    cryptodev_digest_copy,
++    cryptodev_digest_cleanup,
++    EVP_PKEY_RSA_method,
++    SHA512_CBLOCK,
++    sizeof(EVP_MD *) + sizeof(struct dev_crypto_state),
+ };
+ 
+ const EVP_MD cryptodev_md5 = {
+     NID_md5,
+-    NID_undef,
++    NID_md5WithRSAEncryption,
+     16 /* MD5_DIGEST_LENGTH */ ,
++#if defined(EVP_MD_FLAG_PKEY_METHOD_SIGNATURE) && defined(EVP_MD_FLAG_DIGALGID_ABSENT)
++    EVP_MD_FLAG_PKEY_METHOD_SIGNATURE |
++    EVP_MD_FLAG_DIGALGID_ABSENT |
++#endif
+     EVP_MD_FLAG_ONESHOT,
+     cryptodev_digest_init,
+     cryptodev_digest_update,
+     cryptodev_digest_final,
+     cryptodev_digest_copy,
+     cryptodev_digest_cleanup,
+-    EVP_PKEY_NULL_method,
++    EVP_PKEY_RSA_method,
+     64 /* MD5_CBLOCK */ ,
+-    sizeof(struct dev_crypto_state),
++    sizeof(EVP_MD *) + sizeof(struct dev_crypto_state),
+ };
+ 
+ # endif                         /* USE_CRYPTODEV_DIGESTS */
+@@ -998,6 +1086,18 @@ cryptodev_engine_digests(ENGINE *e, const EVP_MD **digest,
+     case NID_sha1:
+         *digest = &cryptodev_sha1;
+         break;
++    case NID_sha224:
++        *digest = &cryptodev_sha224;
++        break;
++    case NID_sha256:
++        *digest = &cryptodev_sha256;
++        break;
++    case NID_sha384:
++        *digest = &cryptodev_sha384;
++        break;
++    case NID_sha512:
++        *digest = &cryptodev_sha512;
++        break;
+     default:
+ # endif                         /* USE_CRYPTODEV_DIGESTS */
+         *digest = NULL;
+@@ -1028,7 +1128,7 @@ static int bn2crparam(const BIGNUM *a, struct crparam *crp)
+         return (1);
+     memset(b, 0, bytes);
+ 
+-    crp->crp_p = (caddr_t) b;
++    crp->crp_p = (void*) b;
+     crp->crp_nbits = bits;
+ 
+     for (i = 0, j = 0; i < a->top; i++) {
+@@ -1291,7 +1391,7 @@ static DSA_SIG *cryptodev_dsa_do_sign(const unsigned char *dgst, int dlen,
+     kop.crk_op = CRK_DSA_SIGN;
+ 
+     /* inputs: dgst dsa->p dsa->q dsa->g dsa->priv_key */
+-    kop.crk_param[0].crp_p = (caddr_t) dgst;
++    kop.crk_param[0].crp_p = (void*) dgst;
+     kop.crk_param[0].crp_nbits = dlen * 8;
+     if (bn2crparam(dsa->p, &kop.crk_param[1]))
+         goto err;
+@@ -1334,7 +1434,7 @@ cryptodev_dsa_verify(const unsigned char *dgst, int dlen,
+     kop.crk_op = CRK_DSA_VERIFY;
+ 
+     /* inputs: dgst dsa->p dsa->q dsa->g dsa->pub_key sig->r sig->s */
+-    kop.crk_param[0].crp_p = (caddr_t) dgst;
++    kop.crk_param[0].crp_p = (void*) dgst;
+     kop.crk_param[0].crp_nbits = dlen * 8;
+     if (bn2crparam(dsa->p, &kop.crk_param[1]))
+         goto err;
+@@ -1415,9 +1515,10 @@ cryptodev_dh_compute_key(unsigned char *key, const BIGNUM *pub_key, DH *dh)
+         goto err;
+     kop.crk_iparams = 3;
+ 
+-    kop.crk_param[3].crp_p = (caddr_t) key;
+-    kop.crk_param[3].crp_nbits = keylen * 8;
++    kop.crk_param[3].crp_p = (void*) key;
++    kop.crk_param[3].crp_nbits = keylen;
+     kop.crk_oparams = 1;
++    dhret = keylen / 8;
+ 
+     if (ioctl(fd, CIOCKEY, &kop) == -1) {
+         const DH_METHOD *meth = DH_OpenSSL();
+@@ -1487,7 +1588,7 @@ void ENGINE_load_cryptodev(void)
+     put_dev_crypto(fd);
+ 
+     if (!ENGINE_set_id(engine, "cryptodev") ||
+-        !ENGINE_set_name(engine, "BSD cryptodev engine") ||
++        !ENGINE_set_name(engine, "cryptodev engine") ||
+         !ENGINE_set_ciphers(engine, cryptodev_engine_ciphers) ||
+         !ENGINE_set_digests(engine, cryptodev_engine_digests) ||
+         !ENGINE_set_ctrl_function(engine, cryptodev_ctrl) ||
+-- 
+2.11.0
+
diff --git a/patches/openssl-1.0.2l/0201-cryptodev-allow-copying-EVP-contexts.patch b/patches/openssl-1.0.2l/0201-cryptodev-allow-copying-EVP-contexts.patch
new file mode 100644
index 000000000..83a37f130
--- /dev/null
+++ b/patches/openssl-1.0.2l/0201-cryptodev-allow-copying-EVP-contexts.patch
@@ -0,0 +1,205 @@
+From 41b0379ee639c1ba87a13707f4a5836b3823aba5 Mon Sep 17 00:00:00 2001
+From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
+Date: Fri, 4 Jul 2014 08:41:04 +0200
+Subject: [PATCH 2/2] cryptodev: allow copying EVP contexts
+
+[manually rebased to OpenSSL_1_0_2-stable branch]
+Ladislav Michl <ladis@linux-mips.org>
+---
+ crypto/engine/eng_cryptodev.c | 57 ++++++++++++++++++++++++++-----------------
+ 1 file changed, 35 insertions(+), 22 deletions(-)
+
+diff --git a/crypto/engine/eng_cryptodev.c b/crypto/engine/eng_cryptodev.c
+index 75bb85b26..8de3fe415 100644
+--- a/crypto/engine/eng_cryptodev.c
++++ b/crypto/engine/eng_cryptodev.c
+@@ -549,151 +549,164 @@ static int cryptodev_cleanup(EVP_CIPHER_CTX *ctx)
+  * gets called when libcrypto requests a cipher NID.
+  */
+ 
++static int cryptodev_cipher_ctrl(EVP_CIPHER_CTX *ctx, int type, int p1, void *p2)
++{
++    struct dev_crypto_state *state = ctx->cipher_data;
++    struct session_op *sess = &state->d_sess;
++
++    if (type == EVP_CTRL_COPY) {
++        EVP_CIPHER_CTX *out = p2;
++        return cryptodev_init_key(out, sess->key, ctx->iv, 0);
++    }
++
++    return 0;
++}
++
+ /* RC4 */
+ const EVP_CIPHER cryptodev_rc4 = {
+     NID_rc4,
+     1, 16, 0,
+-    EVP_CIPH_VARIABLE_LENGTH,
++    EVP_CIPH_VARIABLE_LENGTH | EVP_CIPH_CUSTOM_COPY,
+     cryptodev_init_key,
+     cryptodev_cipher,
+     cryptodev_cleanup,
+     sizeof(struct dev_crypto_state),
+     NULL,
+     NULL,
+-    NULL
++    cryptodev_cipher_ctrl
+ };
+ 
+ /* DES CBC EVP */
+ const EVP_CIPHER cryptodev_des_cbc = {
+     NID_des_cbc,
+     8, 8, 8,
+-    EVP_CIPH_CBC_MODE,
++    EVP_CIPH_CBC_MODE | EVP_CIPH_CUSTOM_COPY,
+     cryptodev_init_key,
+     cryptodev_cipher,
+     cryptodev_cleanup,
+     sizeof(struct dev_crypto_state),
+     EVP_CIPHER_set_asn1_iv,
+     EVP_CIPHER_get_asn1_iv,
+-    NULL
++    cryptodev_cipher_ctrl
+ };
+ 
+ /* 3DES CBC EVP */
+ const EVP_CIPHER cryptodev_3des_cbc = {
+     NID_des_ede3_cbc,
+     8, 24, 8,
+-    EVP_CIPH_CBC_MODE,
++    EVP_CIPH_CBC_MODE | EVP_CIPH_CUSTOM_COPY,
+     cryptodev_init_key,
+     cryptodev_cipher,
+     cryptodev_cleanup,
+     sizeof(struct dev_crypto_state),
+     EVP_CIPHER_set_asn1_iv,
+     EVP_CIPHER_get_asn1_iv,
+-    NULL
++    cryptodev_cipher_ctrl
+ };
+ 
+ const EVP_CIPHER cryptodev_bf_cbc = {
+     NID_bf_cbc,
+     8, 16, 8,
+-    EVP_CIPH_CBC_MODE,
++    EVP_CIPH_CBC_MODE | EVP_CIPH_CUSTOM_COPY,
+     cryptodev_init_key,
+     cryptodev_cipher,
+     cryptodev_cleanup,
+     sizeof(struct dev_crypto_state),
+     EVP_CIPHER_set_asn1_iv,
+     EVP_CIPHER_get_asn1_iv,
+-    NULL
++    cryptodev_cipher_ctrl
+ };
+ 
+ const EVP_CIPHER cryptodev_cast_cbc = {
+     NID_cast5_cbc,
+     8, 16, 8,
+-    EVP_CIPH_CBC_MODE,
++    EVP_CIPH_CBC_MODE | EVP_CIPH_CUSTOM_COPY,
+     cryptodev_init_key,
+     cryptodev_cipher,
+     cryptodev_cleanup,
+     sizeof(struct dev_crypto_state),
+     EVP_CIPHER_set_asn1_iv,
+     EVP_CIPHER_get_asn1_iv,
+-    NULL
++    cryptodev_cipher_ctrl
+ };
+ 
+ const EVP_CIPHER cryptodev_aes_cbc = {
+     NID_aes_128_cbc,
+     16, 16, 16,
+-    EVP_CIPH_CBC_MODE,
++    EVP_CIPH_CBC_MODE | EVP_CIPH_CUSTOM_COPY,
+     cryptodev_init_key,
+     cryptodev_cipher,
+     cryptodev_cleanup,
+     sizeof(struct dev_crypto_state),
+     EVP_CIPHER_set_asn1_iv,
+     EVP_CIPHER_get_asn1_iv,
+-    NULL
++    cryptodev_cipher_ctrl
+ };
+ 
+ const EVP_CIPHER cryptodev_aes_192_cbc = {
+     NID_aes_192_cbc,
+     16, 24, 16,
+-    EVP_CIPH_CBC_MODE,
++    EVP_CIPH_CBC_MODE | EVP_CIPH_CUSTOM_COPY,
+     cryptodev_init_key,
+     cryptodev_cipher,
+     cryptodev_cleanup,
+     sizeof(struct dev_crypto_state),
+     EVP_CIPHER_set_asn1_iv,
+     EVP_CIPHER_get_asn1_iv,
+-    NULL
++    cryptodev_cipher_ctrl
+ };
+ 
+ const EVP_CIPHER cryptodev_aes_256_cbc = {
+     NID_aes_256_cbc,
+     16, 32, 16,
+-    EVP_CIPH_CBC_MODE,
++    EVP_CIPH_CBC_MODE | EVP_CIPH_CUSTOM_COPY,
+     cryptodev_init_key,
+     cryptodev_cipher,
+     cryptodev_cleanup,
+     sizeof(struct dev_crypto_state),
+     EVP_CIPHER_set_asn1_iv,
+     EVP_CIPHER_get_asn1_iv,
+-    NULL
++    cryptodev_cipher_ctrl
+ };
+ 
+ # ifdef CRYPTO_AES_CTR
+ const EVP_CIPHER cryptodev_aes_ctr = {
+     NID_aes_128_ctr,
+     16, 16, 14,
+-    EVP_CIPH_CTR_MODE,
++    EVP_CIPH_CTR_MODE | EVP_CIPH_CUSTOM_COPY,
+     cryptodev_init_key,
+     cryptodev_cipher,
+     cryptodev_cleanup,
+     sizeof(struct dev_crypto_state),
+     EVP_CIPHER_set_asn1_iv,
+     EVP_CIPHER_get_asn1_iv,
+-    NULL
++    cryptodev_cipher_ctrl
+ };
+ 
+ const EVP_CIPHER cryptodev_aes_ctr_192 = {
+     NID_aes_192_ctr,
+     16, 24, 14,
+-    EVP_CIPH_CTR_MODE,
++    EVP_CIPH_CTR_MODE | EVP_CIPH_CUSTOM_COPY,
+     cryptodev_init_key,
+     cryptodev_cipher,
+     cryptodev_cleanup,
+     sizeof(struct dev_crypto_state),
+     EVP_CIPHER_set_asn1_iv,
+     EVP_CIPHER_get_asn1_iv,
+-    NULL
++    cryptodev_cipher_ctrl
+ };
+ 
+ const EVP_CIPHER cryptodev_aes_ctr_256 = {
+     NID_aes_256_ctr,
+     16, 32, 14,
+-    EVP_CIPH_CTR_MODE,
++    EVP_CIPH_CTR_MODE | EVP_CIPH_CUSTOM_COPY,
+     cryptodev_init_key,
+     cryptodev_cipher,
+     cryptodev_cleanup,
+     sizeof(struct dev_crypto_state),
+     EVP_CIPHER_set_asn1_iv,
+     EVP_CIPHER_get_asn1_iv,
+-    NULL
++    cryptodev_cipher_ctrl
+ };
+ # endif
+ /*
+-- 
+2.11.0
+
diff --git a/patches/openssl-1.0.2l/series b/patches/openssl-1.0.2l/series
index d81c31bd3..799aff682 100644
--- a/patches/openssl-1.0.2l/series
+++ b/patches/openssl-1.0.2l/series
@@ -15,4 +15,7 @@
 #tag:ptx --start-number 100
 0100-Configure-don-t-ask-dpkg-buildflags-for-more-flags.patch
 0101-fix-parallel-building.patch
+#tag:cryptodev --start-number 200
+0200-cryptodev-Fix-issue-with-signature-generation.patch
+0201-cryptodev-allow-copying-EVP-contexts.patch
 # 360ce8e8a892ba20f190a8f9d6aa170a  - git-ptx-patches magic
diff --git a/rules/openssl.in b/rules/openssl.in
index 096b398d3..7c34a308d 100644
--- a/rules/openssl.in
+++ b/rules/openssl.in
@@ -4,6 +4,7 @@ menuconfig OPENSSL
 	tristate
 	select LIBC_DL
 	select GCCLIBS_GCC_S
+	select CRYPTODEV		if OPENSSL_CRYPTODEV
 	prompt "openssl                       "
 	help
 	  Secure Socket Layer (SSL) binary and related cryptographic tools
@@ -23,6 +24,21 @@ menuconfig OPENSSL
 
 if OPENSSL
 
+config OPENSSL_CRYPTODEV
+	bool
+	prompt "use cryptodev hw acceleration"
+	help
+	  Enable the BSD cryptodev engine even if we are not using BSD.
+
+config OPENSSL_CRYPTODEV_DIGESTS
+	bool
+	depends on OPENSSL_CRYPTODEV
+	prompt "use cryptodev digests"
+	help
+	  Once BSD cryptodev engine enabled you can also enable the
+	  use of cryptodev digests, which is usually slower unless
+	  you have large amounts data.
+
 config OPENSSL_BIN
 	bool "install openssl tools"
 	help
diff --git a/rules/openssl.make b/rules/openssl.make
index 1cd6e4075..250853403 100644
--- a/rules/openssl.make
+++ b/rules/openssl.make
@@ -77,6 +77,13 @@ OPENSSL_CONF_OPT := \
 	--install_prefix=$(OPENSSL_PKGDIR) \
 	shared
 
+ifdef PTXCONF_OPENSSL_CRYPTODEV
+OPENSSL_CONF_OPT += -DHAVE_CRYPTODEV
+endif
+ifdef PTXCONF_OPENSSL_CRYPTODEV_DIGESTS
+OPENSSL_CONF_OPT += -DUSE_CRYPTODEV_DIGESTS
+endif
+
 OPENSSL_INSTALL_OPT := \
 	install_sw
 
-- 
2.11.0


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [ptxdist] [PATCH 3/3] gnutls: add cryptodev support
  2017-06-24 13:47 [ptxdist] [RFC/PATCH 0/3] cryptodev Ladislav Michl
  2017-06-24 13:48 ` [ptxdist] [PATCH 1/3] cryptodev: new package Ladislav Michl
  2017-06-24 13:49 ` [ptxdist] [PATCH 2/3] openssl: add cryptodev support Ladislav Michl
@ 2017-06-24 13:49 ` Ladislav Michl
  2017-06-30 14:36 ` [ptxdist] [RFC/PATCH 0/3] cryptodev Michael Olbrich
  3 siblings, 0 replies; 13+ messages in thread
From: Ladislav Michl @ 2017-06-24 13:49 UTC (permalink / raw)
  To: ptxdist

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 rules/gnutls.in   | 7 +++++++
 rules/gnutls.make | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/rules/gnutls.in b/rules/gnutls.in
index 73e610fe6..cf44ef126 100644
--- a/rules/gnutls.in
+++ b/rules/gnutls.in
@@ -6,6 +6,7 @@ menuconfig GNUTLS
 	select LIBGCRYPT
 	select LIBTASN1
 	select NETTLE
+	select CRYPTODEV	if GNUTLS_CRYPTODEV
 	select OPENSSL		if GNUTLS_OPENSSL
 	prompt "gnutls                        "
 	help
@@ -19,6 +20,12 @@ menuconfig GNUTLS
 
 if GNUTLS
 
+config GNUTLS_CRYPTODEV
+	bool
+	prompt "enable cryptodev support"
+	help
+	  Enable the BSD cryptodev engine even if we are not using BSD.
+
 config GNUTLS_OPENSSL
 	bool
 	prompt "openssl compatibility"
diff --git a/rules/gnutls.make b/rules/gnutls.make
index 3626a38f0..7955375a4 100644
--- a/rules/gnutls.make
+++ b/rules/gnutls.make
@@ -49,7 +49,7 @@ GNUTLS_CONF_OPT		:= \
 	--enable-dhe \
 	--enable-ecdhe \
 	--enable-openpgp-authentication \
-	--disable-cryptodev \
+	--$(call ptx/endis, PTXCONF_GNUTLS_CRYPTODEV)-cryptodev \
 	--enable-ocsp \
 	--enable-session-tickets \
 	--$(call ptx/endis, PTXCONF_GNUTLS_OPENSSL)-openssl-compatibility \
-- 
2.11.0


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
  2017-06-24 13:47 [ptxdist] [RFC/PATCH 0/3] cryptodev Ladislav Michl
                   ` (2 preceding siblings ...)
  2017-06-24 13:49 ` [ptxdist] [PATCH 3/3] gnutls: " Ladislav Michl
@ 2017-06-30 14:36 ` Michael Olbrich
  2017-06-30 19:25   ` Ladislav Michl
  3 siblings, 1 reply; 13+ messages in thread
From: Michael Olbrich @ 2017-06-30 14:36 UTC (permalink / raw)
  To: ptxdist

Hi,

On Sat, Jun 24, 2017 at 03:47:51PM +0200, Ladislav Michl wrote:
> This serie adds support for cryptodev hardware acceleration.
> However, there's one issue unresolved: cryptodev module
> loading.
> As we have three different modutils implementations available
> and also supporting systemd and sysv init it is a bit messy
> to generate proper config to load cryptodev at boot time.
> So we could either leave module loading to BSP or do something
> on ptxdist level. Thoughts?

I'm not sure I like this. Keeping up to date with crypto stuff is hard
enough as it is. I don't like adding a out-of-tree kernel module into the
mix.
I wouldn't mind the options for gnutls and openssl but those require
crypto/cryptodev.h, right? Where is this coming from anyways?
cryptodev.install is empty, so not from there.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
  2017-06-30 14:36 ` [ptxdist] [RFC/PATCH 0/3] cryptodev Michael Olbrich
@ 2017-06-30 19:25   ` Ladislav Michl
  2017-07-02 20:30     ` Clemens Gruber
  0 siblings, 1 reply; 13+ messages in thread
From: Ladislav Michl @ 2017-06-30 19:25 UTC (permalink / raw)
  To: ptxdist

On Fri, Jun 30, 2017 at 04:36:21PM +0200, Michael Olbrich wrote:
> Hi,
> 
> On Sat, Jun 24, 2017 at 03:47:51PM +0200, Ladislav Michl wrote:
> > This serie adds support for cryptodev hardware acceleration.
> > However, there's one issue unresolved: cryptodev module
> > loading.
> > As we have three different modutils implementations available
> > and also supporting systemd and sysv init it is a bit messy
> > to generate proper config to load cryptodev at boot time.
> > So we could either leave module loading to BSP or do something
> > on ptxdist level. Thoughts?
> 
> I'm not sure I like this. Keeping up to date with crypto stuff is hard
> enough as it is. I don't like adding a out-of-tree kernel module into the
> mix.

Fair enough, but note this module is there for long time and still properly
maintained.

> I wouldn't mind the options for gnutls and openssl but those require
> crypto/cryptodev.h, right? Where is this coming from anyways?
> cryptodev.install is empty, so not from there.

Unfortunately from cryptodev.targetinstall as cryprodev's Makefile reads:

install: modules_install

modules_install:
	$(MAKE) $(KERNEL_MAKE_OPTS) modules_install
	install -m 644 -D crypto/cryptodev.h $(DESTDIR)/$(includedir)/crypto/cryptodev.h

regards,
	ladis

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
  2017-06-30 19:25   ` Ladislav Michl
@ 2017-07-02 20:30     ` Clemens Gruber
  2017-07-02 22:03       ` Alexander Dahl
  2017-07-11  8:56       ` Ladislav Michl
  0 siblings, 2 replies; 13+ messages in thread
From: Clemens Gruber @ 2017-07-02 20:30 UTC (permalink / raw)
  To: ptxdist

Hi,

On Fri, Jun 30, 2017 at 09:25:04PM +0200, Ladislav Michl wrote:
> On Fri, Jun 30, 2017 at 04:36:21PM +0200, Michael Olbrich wrote:
> > Hi,
> > 
> > On Sat, Jun 24, 2017 at 03:47:51PM +0200, Ladislav Michl wrote:
> > > This serie adds support for cryptodev hardware acceleration.
> > > However, there's one issue unresolved: cryptodev module
> > > loading.
> > > As we have three different modutils implementations available
> > > and also supporting systemd and sysv init it is a bit messy
> > > to generate proper config to load cryptodev at boot time.
> > > So we could either leave module loading to BSP or do something
> > > on ptxdist level. Thoughts?
> > 
> > I'm not sure I like this. Keeping up to date with crypto stuff is hard
> > enough as it is. I don't like adding a out-of-tree kernel module into the
> > mix.
> 
> Fair enough, but note this module is there for long time and still properly
> maintained.

I am wondering about the performance improvements when using the
cryptodev openssl engine. There must be some cost for the context
switches, but this is probably outweighed by the offloading.
Did you for example run openssl speed aes-128-cbc before and after?
And on what platform did you try it?

Thanks,
Clemens

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
  2017-07-02 20:30     ` Clemens Gruber
@ 2017-07-02 22:03       ` Alexander Dahl
  2017-07-03  6:56         ` Robert Schwebel
  2017-07-11  8:56       ` Ladislav Michl
  1 sibling, 1 reply; 13+ messages in thread
From: Alexander Dahl @ 2017-07-02 22:03 UTC (permalink / raw)
  To: ptxdist


[-- Attachment #1.1: Type: text/plain, Size: 945 bytes --]

Hei hei,

On Sun, Jul 02, 2017 at 10:30:30PM +0200, Clemens Gruber wrote:
> I am wondering about the performance improvements when using the
> cryptodev openssl engine. There must be some cost for the context
> switches, but this is probably outweighed by the offloading.
> Did you for example run openssl speed aes-128-cbc before and after?
> And on what platform did you try it?

fli4l [1] uses cryptodev and the experience there is, it depends on
the platform. Some platforms benefit a lot, especially for OpenVPN,
others not so much. Depends on what the CPU offers and how fast the
system in general is.

Greets
Alex

[1] http://www.fli4l.de/

-- 
»With the first link, the chain is forged. The first speech censured, 
the first thought forbidden, the first freedom denied, chains us all 
irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie)
*** GnuPG-FP: C28E E6B9 0263 95CF 8FAF  08FA 34AD CD00 7221 5CC6 ***

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 91 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
  2017-07-02 22:03       ` Alexander Dahl
@ 2017-07-03  6:56         ` Robert Schwebel
  2017-07-03  7:29           ` Alexander Dahl
  2017-07-10 14:11           ` Ladislav Michl
  0 siblings, 2 replies; 13+ messages in thread
From: Robert Schwebel @ 2017-07-03  6:56 UTC (permalink / raw)
  To: ptxdist

On Mon, Jul 03, 2017 at 12:03:26AM +0200, Alexander Dahl wrote:
> On Sun, Jul 02, 2017 at 10:30:30PM +0200, Clemens Gruber wrote:
> > I am wondering about the performance improvements when using the
> > cryptodev openssl engine. There must be some cost for the context
> > switches, but this is probably outweighed by the offloading.
> > Did you for example run openssl speed aes-128-cbc before and after?
> > And on what platform did you try it?
> 
> fli4l [1] uses cryptodev and the experience there is, it depends on
> the platform. Some platforms benefit a lot, especially for OpenVPN,
> others not so much. Depends on what the CPU offers and how fast the
> system in general is.

Do you know why the module is not in mainline? Is there a discussion
where the kernel maintainers motivate why they don't like this solution?

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
  2017-07-03  6:56         ` Robert Schwebel
@ 2017-07-03  7:29           ` Alexander Dahl
  2017-07-10 14:11           ` Ladislav Michl
  1 sibling, 0 replies; 13+ messages in thread
From: Alexander Dahl @ 2017-07-03  7:29 UTC (permalink / raw)
  To: ptxdist; +Cc: Robert Schwebel, fli4l-dev


[-- Attachment #1.1: Type: text/plain, Size: 1759 bytes --]

Hei hei,

cross post following … ;-)

On Mon, Jul 03, 2017 at 08:56:42AM +0200, Robert Schwebel wrote:
> On Mon, Jul 03, 2017 at 12:03:26AM +0200, Alexander Dahl wrote:
> > On Sun, Jul 02, 2017 at 10:30:30PM +0200, Clemens Gruber wrote:
> > > I am wondering about the performance improvements when using the
> > > cryptodev openssl engine. There must be some cost for the context
> > > switches, but this is probably outweighed by the offloading.
> > > Did you for example run openssl speed aes-128-cbc before and after?
> > > And on what platform did you try it?
> > 
> > fli4l [1] uses cryptodev and the experience there is, it depends on
> > the platform. Some platforms benefit a lot, especially for OpenVPN,
> > others not so much. Depends on what the CPU offers and how fast the
> > system in general is.
> 
> Do you know why the module is not in mainline? Is there a discussion
> where the kernel maintainers motivate why they don't like this solution?

Sorry, I do not know. IIRC did we switch from some other hardware
acceleration approach in fli4l some time ago, but I can't remember any
details, and I doubt your question was discussed within the fli4l
team. The ticket in the fli4l bugtracker is this one:

https://ssl.nettworks.org/bugs/browse/FFL-946 

(You may notice it's a German project ;-) ).

I forward this conversation to the (not yet open) fli4l developer
list, maybe Christoph Schulz has more insights?

Greets
Alex

-- 
»With the first link, the chain is forged. The first speech censured, 
the first thought forbidden, the first freedom denied, chains us all 
irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie)
*** GnuPG-FP: C28E E6B9 0263 95CF 8FAF  08FA 34AD CD00 7221 5CC6 ***

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 91 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
  2017-07-03  6:56         ` Robert Schwebel
  2017-07-03  7:29           ` Alexander Dahl
@ 2017-07-10 14:11           ` Ladislav Michl
  2017-07-17  8:56             ` Michael Olbrich
  1 sibling, 1 reply; 13+ messages in thread
From: Ladislav Michl @ 2017-07-10 14:11 UTC (permalink / raw)
  To: ptxdist

On Mon, Jul 03, 2017 at 08:56:42AM +0200, Robert Schwebel wrote:
> On Mon, Jul 03, 2017 at 12:03:26AM +0200, Alexander Dahl wrote:
> > On Sun, Jul 02, 2017 at 10:30:30PM +0200, Clemens Gruber wrote:
> > > I am wondering about the performance improvements when using the
> > > cryptodev openssl engine. There must be some cost for the context
> > > switches, but this is probably outweighed by the offloading.
> > > Did you for example run openssl speed aes-128-cbc before and after?
> > > And on what platform did you try it?
> > 
> > fli4l [1] uses cryptodev and the experience there is, it depends on
> > the platform. Some platforms benefit a lot, especially for OpenVPN,
> > others not so much. Depends on what the CPU offers and how fast the
> > system in general is.
> 
> Do you know why the module is not in mainline? Is there a discussion
> where the kernel maintainers motivate why they don't like this solution?

The module itself is 10+ years old and it is highly unlikely it will be
ever merged as it uses ioctl approach - makes API compatible with OpenBSD.
Meawhile AF_ALG API was introduced without anyone really interested (people
are still using /dev/crypto). Also see this comparsion:
http://cryptodev-linux.org/comparison.html

	ladis

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
  2017-07-02 20:30     ` Clemens Gruber
  2017-07-02 22:03       ` Alexander Dahl
@ 2017-07-11  8:56       ` Ladislav Michl
  1 sibling, 0 replies; 13+ messages in thread
From: Ladislav Michl @ 2017-07-11  8:56 UTC (permalink / raw)
  To: ptxdist

On Sun, Jul 02, 2017 at 10:30:30PM +0200, Clemens Gruber wrote:
> I am wondering about the performance improvements when using the
> cryptodev openssl engine. There must be some cost for the context
> switches, but this is probably outweighed by the offloading.
> Did you for example run openssl speed aes-128-cbc before and after?
> And on what platform did you try it?

The cost of the context switches is notable only for small payloads,
bigger payload makes hw acceleration more usefull. Bellow is openssl
speed test result as run on IGEPv2 board with DM3730 (OMAP3630) -
second line is using cryptodev engine
(omap-aes 480c5000.aes: OMAP AES hw accel rev: 2.6):
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes     256 bytes   1024 bytes   8192 bytes
aes-128-cbc      25210.41k    32946.13k    35359.47k    36149.68k    36203.09k
aes-128-cbc       8821.87k    55293.26k    34594.13k   308582.40k         infk

	ladis

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [ptxdist] [RFC/PATCH 0/3] cryptodev
  2017-07-10 14:11           ` Ladislav Michl
@ 2017-07-17  8:56             ` Michael Olbrich
  0 siblings, 0 replies; 13+ messages in thread
From: Michael Olbrich @ 2017-07-17  8:56 UTC (permalink / raw)
  To: ptxdist

On Mon, Jul 10, 2017 at 04:11:20PM +0200, Ladislav Michl wrote:
> On Mon, Jul 03, 2017 at 08:56:42AM +0200, Robert Schwebel wrote:
> > On Mon, Jul 03, 2017 at 12:03:26AM +0200, Alexander Dahl wrote:
> > > On Sun, Jul 02, 2017 at 10:30:30PM +0200, Clemens Gruber wrote:
> > > > I am wondering about the performance improvements when using the
> > > > cryptodev openssl engine. There must be some cost for the context
> > > > switches, but this is probably outweighed by the offloading.
> > > > Did you for example run openssl speed aes-128-cbc before and after?
> > > > And on what platform did you try it?
> > > 
> > > fli4l [1] uses cryptodev and the experience there is, it depends on
> > > the platform. Some platforms benefit a lot, especially for OpenVPN,
> > > others not so much. Depends on what the CPU offers and how fast the
> > > system in general is.
> > 
> > Do you know why the module is not in mainline? Is there a discussion
> > where the kernel maintainers motivate why they don't like this solution?
> 
> The module itself is 10+ years old and it is highly unlikely it will be
> ever merged as it uses ioctl approach - makes API compatible with OpenBSD.
> Meawhile AF_ALG API was introduced without anyone really interested (people
> are still using /dev/crypto). Also see this comparsion:
> http://cryptodev-linux.org/comparison.html

I'm not concerned about upstream, but keeping it up to date in PTXdist.
As long as it's not in the mainline kernel, we have a separate packages
that needs to be maintained.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2017-07-17  8:56 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-24 13:47 [ptxdist] [RFC/PATCH 0/3] cryptodev Ladislav Michl
2017-06-24 13:48 ` [ptxdist] [PATCH 1/3] cryptodev: new package Ladislav Michl
2017-06-24 13:49 ` [ptxdist] [PATCH 2/3] openssl: add cryptodev support Ladislav Michl
2017-06-24 13:49 ` [ptxdist] [PATCH 3/3] gnutls: " Ladislav Michl
2017-06-30 14:36 ` [ptxdist] [RFC/PATCH 0/3] cryptodev Michael Olbrich
2017-06-30 19:25   ` Ladislav Michl
2017-07-02 20:30     ` Clemens Gruber
2017-07-02 22:03       ` Alexander Dahl
2017-07-03  6:56         ` Robert Schwebel
2017-07-03  7:29           ` Alexander Dahl
2017-07-10 14:11           ` Ladislav Michl
2017-07-17  8:56             ` Michael Olbrich
2017-07-11  8:56       ` Ladislav Michl

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox