Re: [Cryptodev-linux-devel] [PATCH] Fix ablkcipher algorithms usage in v4.8+ kernels
On 2/9/2017 12:35 PM, Phil Sutter wrote: > Hi, > > On Wed, Feb 08, 2017 at 04:41:50PM +0000, Horia Geantă wrote: >> Phil? > > I intentionally left this out since (according to my INBOX) there are > open questions from Michael. Did you sort this out in private? > It seems that somehow you've been removed from Cc. The discussion is in the archives: https://mail.gna.org/public/cryptodev-linux-devel/2016-11/msg3.html https://mail.gna.org/public/cryptodev-linux-devel/2016-11/msg4.html https://mail.gna.org/public/cryptodev-linux-devel/2016-11/msg5.html and AFAICT the conclusion was that the patch is needed. Thanks, Horia ___ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
[Cryptodev-linux-devel] [PATCH] Fix ablkcipher algorithms usage in v4.8+ kernels
ablkcipher API is not completely removed from kernels <= v4.9.
Thus it's still valid to use ablkcipher algorithms.
Fix the case when implementers register ablkcipher algorithms
and cryptodev casts them to skcipher without checking their type.
Note: alg returned by crypto_ablkcipher_alg() is no longer checked
to be non-NULL. This is guaranteed by the fact that ablkcipher_tfm
(out->async.s) is valid.
Fixes: cb186f682679 ("Support skcipher in addition to ablkcipher API")
Tested-by: Cristian Stoica <cristian.sto...@nxp.com>
Signed-off-by: Horia Geantă <horia.gea...@nxp.com>
---
cipherapi.h | 4
cryptlib.c | 56
2 files changed, 44 insertions(+), 16 deletions(-)
diff --git a/cipherapi.h b/cipherapi.h
index 07d992333ad7..b6ed6c279350 100644
--- a/cipherapi.h
+++ b/cipherapi.h
@@ -6,12 +6,10 @@
#if (LINUX_VERSION_CODE < KERNEL_VERSION(4, 8, 0))
# include
-typedef struct ablkcipher_alg cryptodev_blkcipher_alg_t;
typedef struct crypto_ablkcipher cryptodev_crypto_blkcipher_t;
typedef struct ablkcipher_request cryptodev_blkcipher_request_t;
# define cryptodev_crypto_alloc_blkcipher crypto_alloc_ablkcipher
-# define cryptodev_crypto_blkcipher_alg crypto_ablkcipher_alg
# define cryptodev_crypto_blkcipher_blocksize crypto_ablkcipher_blocksize
# define cryptodev_crypto_blkcipher_ivsize crypto_ablkcipher_ivsize
# define cryptodev_crypto_blkcipher_alignmask crypto_ablkcipher_alignmask
@@ -37,12 +35,10 @@ static inline void
cryptodev_blkcipher_request_free(cryptodev_blkcipher_request_
#else
#include
-typedef struct skcipher_alg cryptodev_blkcipher_alg_t;
typedef struct crypto_skcipher cryptodev_crypto_blkcipher_t;
typedef struct skcipher_request cryptodev_blkcipher_request_t;
# define cryptodev_crypto_alloc_blkcipher crypto_alloc_skcipher
-# define cryptodev_crypto_blkcipher_alg crypto_skcipher_alg
# define cryptodev_crypto_blkcipher_blocksize crypto_skcipher_blocksize
# define cryptodev_crypto_blkcipher_ivsize crypto_skcipher_ivsize
# define cryptodev_crypto_blkcipher_alignmask crypto_skcipher_alignmask
diff --git a/cryptlib.c b/cryptlib.c
index 5a6e0ba5fe88..2c6028ee2b23 100644
--- a/cryptlib.c
+++ b/cryptlib.c
@@ -38,6 +38,7 @@
#include "cryptodev_int.h"
#include "cipherapi.h"
+extern const struct crypto_type crypto_givcipher_type;
static void cryptodev_complete(struct crypto_async_request *req, int err)
{
@@ -121,6 +122,19 @@ error:
return ret;
}
+/* Was correct key length supplied? */
+static int check_key_size(size_t keylen, const char *alg_name,
+ unsigned int min_keysize, unsigned int max_keysize)
+{
+ if (max_keysize > 0 && unlikely((keylen < min_keysize) ||
+ (keylen > max_keysize))) {
+ ddebug(1, "Wrong keylen '%zu' for algorithm '%s'. Use %u to
%u.",
+ keylen, alg_name, min_keysize, max_keysize);
+ return -EINVAL;
+ }
+
+ return 0;
+}
int cryptodev_cipher_init(struct cipher_data *out, const char *alg_name,
uint8_t *keyp, size_t keylen, int stream, int
aead)
@@ -128,7 +142,12 @@ int cryptodev_cipher_init(struct cipher_data *out, const
char *alg_name,
int ret;
if (aead == 0) {
- cryptodev_blkcipher_alg_t *alg;
+ unsigned int min_keysize, max_keysize;
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 8, 0))
+ struct crypto_tfm *tfm;
+#else
+ struct ablkcipher_alg *alg;
+#endif
out->async.s = cryptodev_crypto_alloc_blkcipher(alg_name, 0, 0);
if (unlikely(IS_ERR(out->async.s))) {
@@ -136,18 +155,31 @@ int cryptodev_cipher_init(struct cipher_data *out, const
char *alg_name,
return -EINVAL;
}
- alg = cryptodev_crypto_blkcipher_alg(out->async.s);
- if (alg != NULL) {
- /* Was correct key length supplied? */
- if (alg->max_keysize > 0 &&
- unlikely((keylen < alg->min_keysize) ||
- (keylen > alg->max_keysize))) {
- ddebug(1, "Wrong keylen '%zu' for algorithm
'%s'. Use %u to %u.",
- keylen, alg_name,
alg->min_keysize, alg->max_keysize);
- ret = -EINVAL;
- goto error;
- }
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 8, 0))
+ tfm = crypto_skcipher_tfm(out->async.s);
+ if ((tfm->__crt_alg->cra_type == _ablkcipher_type) ||
+ (tfm->__crt_alg->cra_type == _givcipher_type)) {
+
Re: [Cryptodev-linux-devel] [PATCH v2] Replace INIT_COMPLETION with reinit_completion.
Hi Phil, On 1/23/2014 4:42 AM, Phil Sutter wrote: On Thu, Jan 16, 2014 at 12:18:08PM +0200, Horia Geanta wrote: From: Cosmin Paraschiv cosmin.parasc...@freescale.com In the 3.13-rc1 Linux kernel, the INIT_COMPLETION macro has been replaced with an inline function, reinit_completion [1][2]. We are currently using the 3.13-rc3 Linux kernel, which leads to the following error: cryptlib.c:279:2: error: implicit declaration of function 'INIT_COMPLETION' [-Werror=implicit-function-declaration] INIT_COMPLETION(cdata-async.result-completion); [1] https://github.com/torvalds/linux/commit/c32f74ab2872994bc8336ed367313da3139350ca [2] https://github.com/torvalds/linux/commit/62026aedaacedbe1ffe94a3599ad4acd8ecdf587 Applied, thanks a lot. Thanks. Note that the subject of the commit message was left out somehow... Regards, Horia ___ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
Re: [Cryptodev-linux-devel] [PATCH] add support for COMPAT_CIOCAUTHCRYPT ioctl()
On 12/11/2013 8:37 AM, Nikos Mavrogiannopoulos wrote: On Mon, 2013-12-09 at 19:41 +0200, Horia Geanta wrote: Needed for 64b kernel with 32b user space. Signed-off-by: Horia Geanta horia.gea...@freescale.com Reviewed-by: Mircea Pop mircea@freescale.com Reviewed-by: Cristian Stoica cristian.sto...@freescale.com Tested-by: Cristian Stoica cristian.sto...@freescale.com --- authenc.c | 80 +++ cryptodev_int.h | 41 ioctl.c | 16 +++ 3 files changed, 137 insertions(+), 0 deletions(-) Hello, This does not compile. You seem to use dst_len that isn't there in the definitions of these structures. Sorry for that. There are a few more patches that need to be upstreamed. We internally modified the interface (struct crypt_auth_op), so that user provides both source buffer length (len) and destination buffer length (dst_len). Is this acceptable? Thanks, Horia ___ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
Re: [Cryptodev-linux-devel] [PATCH] add support for COMPAT_CIOCAUTHCRYPT ioctl()
On 12/12/2013 5:30 PM, Nikos Mavrogiannopoulos wrote: On Thu, Dec 12, 2013 at 3:35 PM, Horia Geantă horia.gea...@freescale.com wrote: Hello, This does not compile. You seem to use dst_len that isn't there in the definitions of these structures. Sorry for that. There are a few more patches that need to be upstreamed. We internally modified the interface (struct crypt_auth_op), so that user provides both source buffer length (len) and destination buffer length (dst_len). Is this acceptable? It sounds reasonable for future extensibility, but I'm curious why did you need that? In existing AEAD cipher there is no padding involved so the destination size is known. This has to do with adding TLS record offloading support in kernel. The kernel patches haven't been sent out for review yet. I am sending the cryptodev patchset as [RFC]. Note that patch 9/9 add support for composite TLS(SHA1,AES) algorithm offload depends on the kernel crypto API changes (which might not be accepted as is). More exactly, the template name tls10(hmac(sha1),cbc(aes)) might change. Patch 7/9 adds the dst_len. Without it, there are issues with dst len in __crypto_auth_run_zc for the case (caop-flags COP_FLAG_AEAD_TLS_TYPE ses_ptr-cdata.aead != 0). We fall in this case when offloading one-shot TLS (CIOCAUTHCRYPT) for stitched (hmac(sha1),aes(cbc)). For now, we are performing tests using OpenSSL 1.0.1e, with modified cryptodev-engine, see add support for TLS algorithms offload patch. Regards, Horia ___ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
