Bug 366709 – Package request: Cryptodev for Linux and cryptodev use flag for OpenSSL

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description klockren 2011-05-10 07:07:10 UTC]

Some hardware, for example the Marvell Kirkwood ARM CPU (SheevaPlug, DreamPlug etc) has instructions for AES acceleration, but OpenSSL and other user space applications lack the support of it.

With the Cryptodev module http://home.gna.org/cryptodev-linux/ the device /dev/crypto is created. Now userspace applications can access the cryptographic device through /dev/crypto. With the OCF patch, http://sourceforge.net/projects/ocf-linux/ , OpenSSL gets an engine for cryptodev.

Reproducible: Always

[Comment 1 klockren 2011-05-10 07:10:12 UTC]

Created attachment 272707 [details]
Differences in OpenSSL speed with and without cryptodev

This test is performed on a Marvell Kirkwood ARM CPU (DreamPlug).

The ebuild for OpenSSL 0.9.8n was patched with the OCF patches and --with-cryptodev added to configure.

[Comment 2 ssmyth 2011-07-28 19:31:54 UTC]

Additionally, with some ARM platforms the gentoo.config-1.0.0 file goes to a target of arm4-linux, which does not accept the definitions needed to enable cryptodev support.  All LE ARM platforms should go to generic32-linux and probably include the following defines for the ${config} parameters in the ebuild files since if "cryptodev" is provided as a USE flag it is already in openssl v1.0.0d:

-DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DHASH_MAX_LEN=64

The one down side is that emerge segfaults when openssl uses /dev/crypto with cryptodev kernel module and the hardware engines I tested so far (entered as separate defect rather than this request).  I am guessing this is a python/SSL issue but no research into it as of yet.

[Comment 3 robert 2011-10-17 11:31:24 UTC]

wrote two little patches for 
openssl-1.0.0e
and for openssh to use cryptodev if the kernel was
patched (and compiled) with ocf
(added the requested use flag)

see http://forums.gentoo.org/viewtopic-t-896042.html 

there is still need for an ebuild to do the patching of the kernel,
but i am not skilled at ebuild-writing, as the kernel patch is
no single file and some preparation is needed before patching

i see the same (HUGE) encryption accleration on my amd-geode

[Comment 4 LABBE Corentin 2014-08-01 11:27:39 UTC]

Created attachment 382002 [details]
app-crypt/cryptodev ebuild proposal

This is an ebuild proposal for app-crypt/cryptodev.
For the moment only live ebuild is usable since the latest release (1.6) does not build against current stable kernel.

If nobody want to take maintership of this ebuild, I accept to proxy maintain it.

[Comment 5 LABBE Corentin 2014-08-01 11:33:14 UTC]

Created attachment 382004 [details, diff]
Add cryptodev use flag to dev-libs/openssl

[Comment 6 Markos Chandras (RETIRED) 2014-11-09 14:50:40 UTC]

Is upstream still alive? I see last release was in 2013. Or do you want us to add a -9999 version? If so, we can't add a new useflag to openssl which would depend on a live ebuild.

[Comment 7 Yixun Lan 2014-11-10 01:38:16 UTC]

(In reply to Markos Chandras from comment #6)
> Is upstream still alive? I see last release was in 2013. Or do you want us
> to add a -9999 version? If so, we can't add a new useflag to openssl which
> would depend on a live ebuild.

I'd prefer snapshot version if possible, rather than live version (-9999). especially for infrequent package releases which commited via @proxy-maint team.

[Comment 8 LABBE Corentin 2015-02-25 13:59:56 UTC]

Created attachment 397480 [details]
sys-kernel/cryptodev 1.7 ebuild

[Comment 9 Markos Chandras (RETIRED) 2015-03-14 08:47:31 UTC]

Comment on attachment 397480 [details]
sys-kernel/cryptodev 1.7 ebuild

># Copyright 1999-2013 Gentoo Foundation
># Distributed under the terms of the GNU General Public License v2
># $Header: $
>
>EAPI=5
>inherit linux-info linux-mod
>
>DESCRIPTION="device that allows access to Linux kernel cryptographic drivers"
>HOMEPAGE="http://cryptodev-linux.org/index.html"
>SRC_URI="http://download.gna.org/cryptodev-linux/${PN}-linux-${PV}.tar.gz"
>KEYWORDS="amd64 arm x86"

No stable keywords please

>
>LICENSE="GPL-2"
>SLOT="0"
>IUSE="examples"
>
>DEPEND="virtual/linux-sources"
>RDEPEND=""
>RESTRICT="test"

Why?

>S=${WORKDIR}/${PN}-linux-${PV}
>
>MODULE_NAMES="cryptodev(extra:${S})"
>
>pkg_pretend() {
>	if use kernel_linux ; then
>		CONFIG_CHECK="~CRYPTO ~CRYPTO_BLKCIPHER ~CRYPTO_AEAD"
>		check_extra_config
>	fi
>}
>
>pkg_setup() {
>	if use kernel_linux ; then
>		linux-mod_pkg_setup
>	else
>		die "cryptodev ebuild only support linux"
>	fi

Should this be moved to pkg_pretend instead?

>	BUILD_TARGETS="build"
>}
>
>src_prepare() {
>	# get_unused_fd was removed in 3.19
>	sed -i 's,get_unused_fd(),get_unused_fd_flags(0),' ioctl.c || die
>}
>
>src_compile() {
>	linux-mod_src_compile
>}

Isn't that the default one? So no need to define an src_compile

>
>src_install() {
>	linux-mod_src_install
>	if use examples ; then
>		docinto examples
>		dodoc example/*
>	fi
>	insinto /usr/include/crypto
>	doins crypto/cryptodev.h
>}
>
>pkg_postinst() {
>	linux-mod_pkg_postinst
>}

Same. no need to define a pkg_postinst() either. The one from the eclass will be used by default.

[Comment 10 LABBE Corentin 2015-03-17 07:49:20 UTC]

Created attachment 399084 [details]
sys-kernel/cryptodev 1.7 ebuild

[Comment 11 Markos Chandras (RETIRED) 2015-03-17 21:29:38 UTC]

Hmm having looked at a few ebuilds, it seems your original code with both pkg_pretend and pkg_setup is preferred so I will use that instead. Sorry about that. Apart from that the ebuild looks ok and I will commit it during the weekend. Thanks!

[Comment 12 Markos Chandras (RETIRED) 2015-04-11 12:11:32 UTC]

Committed. Apologies for the delay.