Created attachment 467564 [details] sys-dev/cryptodev-1.8.ebuild Solution minus the version bump camp from: https://www.mail-archive.com/linux-yocto@yoctoproject.org/msg05338.html Fixes the following compile errors: error: implicit declaration of function 'crypto_alloc_ablkcipher' error: too many arguments to function ‘get_user_pages’ The patch for get_user_pages may need an extra argument "write" for < 4.9, but I don't know for what kernel version it kicks in. Here are the patches that go in $(FILESDIR): 1.8-skcipher.patch: diff -Naur cryptodev-linux-1.8-orig/cryptlib.c cryptodev-linux-1.8/cryptlib.c --- cryptodev-linux-1.8-orig/cryptlib.c 2017-03-19 13:35:46.752150621 +0000 +++ cryptodev-linux-1.8/cryptlib.c 2017-03-19 13:37:42.025410936 +0000 @@ -36,6 +36,7 @@ #include <crypto/aead.h> #include <linux/rtnetlink.h> #include <crypto/authenc.h> +#include <crypto/skcipher.h> #include "cryptodev_int.h" @@ -131,11 +132,13 @@ uint8_t *keyp, size_t keylen, int stream, int aead) { int ret; + struct crypto_skcipher *tfm; if (aead == 0) { struct ablkcipher_alg *alg; - out->async.s = crypto_alloc_ablkcipher(alg_name, 0, 0); + tfm = crypto_alloc_skcipher(alg_name, 0, 0); + out->async.s->base = tfm->base; if (unlikely(IS_ERR(out->async.s))) { ddebug(1, "Failed to load cipher %s", alg_name); return -EINVAL; 1.8-user_pages.patch: diff -Naur cryptodev-linux-1.8-orig/zc.c cryptodev-linux-1.8/zc.c --- cryptodev-linux-1.8-orig/zc.c 2017-03-19 13:43:56.035169739 +0000 +++ cryptodev-linux-1.8/zc.c 2017-03-19 13:51:13.044883228 +0000 @@ -59,8 +59,7 @@ } down_read(&mm->mmap_sem); - ret = get_user_pages(task, mm, - (unsigned long)addr, pgcount, write, 0, pg, NULL); + ret = get_user_pages((unsigned long)addr, pgcount, 0, pg, NULL); up_read(&mm->mmap_sem); if (ret != pgcount) return -EINVAL; @@ -119,7 +118,7 @@ else ses->readonly_pages--; - page_cache_release(ses->pages[i]); + put_page(ses->pages[i]); } ses->used_pages = 0; }
I just found out it's already been patched upstream too on github. This patch works on the release 1.8 to fix all compile issues though. This is also got some bugfixes for +4.8 kernels with key size santiy checks. https://github.com/cryptodev-linux/cryptodev-linux/commit/6818263667ca488f9b1c86e36ea624c4ea1c309f https://github.com/cryptodev-linux/cryptodev-linux/commit/26e167f8527b386e6bcb5d69eb2e12e587376a28
Created attachment 467582 [details] sys-kernel/crytodev-9999: github ebuild
I didnt succed to cherrypick patchs, I will add an ebuild using directly the last commit.
Created attachment 467772 [details, diff] sys-kernel/cryptodev-1.8_pre20170209.ebuild
Created attachment 467774 [details] sys-kernel/cryptodev-1.8_pre20170209.ebuild
Created attachment 467776 [details, diff] sys-kernel/cryptodev-9999.ebuild
The live ebuild is now in the tree. As for 1.9_pre20170209 (not 1.8_pre20170209, as according to Gentoo ebuild-naming conventions x.y_preFOO < x.y), I've just asked for a new upstream release (was going to ask Corentin to open an issue for it but since I already had the project GitHub page open, doing it myself was faster) so let's wait for a while, I'd rather avoid adding prereleases to the tree if it can be helped.
commit 394807cb5c5578939124ee7b8d25b3ae57fa44d4 Author: Jeroen Roovers <jer@gentoo.org> Date: Mon Apr 24 09:45:02 2017 +0200 sys-kernel/cryptodev: Version bump (bug #613224). Package-Manager: Portage-2.3.5, Repoman-2.3.2
Thanks guys for putting this upstream. Did you include the git HEAD 9999 ebuild into portage. Here is the thing, I have looked open the openssl cryptodev driver and it's broken in about 20 places. It's too much brokenness to even write up, however gnutls users will benefit from this ebuild as it stands, as with openvpn and a few others that have their own direct /dev/crypto interface. git openssl has been doing a lot of work on it, and so has the the freescale people https://github.com/Freescale/meta-freescale/tree/master/recipes-connectivity/openssl/openssl-qoriq/qoriq On my VPS i got a 30% performance improvement over openssl using evp AES which leaves my head scratching. I get about the same with openssl al_alg so I'm fine. Also tor has got a bug with the cryptodev driver. The maintainer needs to be aware of this and work with the openssl people for either an update or a backport of all the cryptodev patches because it's just so broken. Start putting the cryptodev module into debug mode to see what I mean.
I have patched ebuild for openssl to properly compile cryptodev support (built into libcrypto.so - whilst the other HSMs etc are dynamically loaded) and remove all hardware crypto drivers. I can contribute if you want, but like I said the first thing that happens is a openssl github + freescale patchset backport and that lots of work i'm too lazy to do for a 3% boost over openssl's af_alg.so The driver works in production with some tasks, but completely fails at hashing that breaks even wget connecting to some cites depending on their cyphersuite. It only supports AES_CBC 128 and of course /dev/crypto supports a lot more. I started patching it to support AES_GBC CTR etc then realised it wasn't worth it and too much work. Eventually at least the stuff in 1.2 / 1.3 will trickle down making the /dev/crypto interface usable. The problem with tor is it is hardcore to dynload a cyrpto module you specify in the conf. HardwareAccel 1 (use builtin libcrypto hardware accel possibly hard coded to intel aes instructions haven't checked) AccelName padlock (dynloads the padlock.so openssl cryptoengine) http://archives.seul.org/or/relays/Jun-2016/msg00020.html Sorry to say that af_alg is better for openssl in production as it stands. You might want to put a disclaimer enotice / einfo on the ebuild to save gentoo users all the suffering. Say this works fine with gnutls openvpn and anything but openssl at this time.
Seeing as 1.9 has already been in the tree for several months, I think it's time to close this issue. Luke's comments pertain to a completely different matter which would warrant a separate ticket, or even better a GitHub pull request.
