Bug 706706

Summary:	Cryptodev offload engine is not enabled by default
Product:	[Fedora] Fedora	Reporter:	Gordan Bobic <gordan>
Component:	openssl	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	13	CC:	bjohnson, tmraz
Target Milestone:	---
Target Release:	---
Hardware:	arm9
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-06-27 11:43:30 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Gordan Bobic 2011-05-22 12:50:54 UTC

Description of problem:
The default package doesn't come with cryptodev offload engine enabled by default. It would be nice to have this available by default, since when there is no cryptodev offload available in the kernel, it will simply not be used and it will fall back on the current default behaviour.


Version-Release number of selected component (if applicable):
openssl-1.0.0-1.fc13


Additional info:
In order to build OpenSSL with cryptodev support, two things are required:

1) /usr/include/crypto/cryptodev.h, provided by cryptodev-linux:
http://home.gna.org/cryptodev-linux/

2) A small modification to the openssl spec file:
Change the configure line to:
./Configure \
        --prefix=/usr --openssldir=%{_sysconfdir}/pki/tls ${sslflags} \
        zlib enable-camellia enable-seed enable-tlsext enable-rfc3779 \
        enable-cms enable-md2 no-idea no-mdc2 no-rc5 no-ec no-ecdh no-ecdsa \
        --with-krb5-flavor=MIT --enginesdir=%{_libdir}/openssl/engines \
        --with-krb5-dir=/usr \
        -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DHASH_MAX_LEN=64 \
        shared threads ${sslarch} fips

The benefit is two-fold:
1) Performance is better
2) It frees up the CPU for other things. For example, on Marvell Kirkwood, the CPU usage during crypto operations is close to 0%.

I really think this should be compiled in by default since I cannot see any drawbacks from it.

Comment 1 Bug Zapper 2011-05-30 10:31:39 UTC

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 2 Bug Zapper 2011-06-27 11:43:30 UTC

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 3 Bernard Johnson 2011-06-28 17:05:46 UTC

Gordan, can you bump this to RAWHIDE and reopen?

Comment 4 Tomas Mraz 2011-06-28 18:58:54 UTC

I do not see any reason to enable it by default when there is no cryptodev on the primary Fedora architectures. If you attach a patch for enabling it just on arm provided the cryptodev support is there on the arm kernel, I have no problem with adding it.

Comment 5 Gordan Bobic 2011-06-28 19:45:25 UTC

I don't see why it shouldn't be in by default even on the primary arches because nothing at all is lost by having it enabled. If the hardware and/or kernel driver aren't there, it just won't do anything.

Comment 6 Bernard Johnson 2011-06-29 03:49:38 UTC

I'm guessing that Tomas' comment is based on the fact that it might be confusing to appear to be enabled when on arches that don't support it - it does nothing.  So if it is enabled by default, a note in the spec would surely be appropriate.

In my opinion, this would be the preferred route since there is no maintenance to determine which arches do and do not support this feature.

Due to a change like this in a core package, I would suggest entry into RAWHIDE and not introduce to a released version.

Comment 7 Tomas Mraz 2011-06-29 06:33:01 UTC

No, I will not enable this by default, only for selected architectures.

Comment 8 Gordan Bobic 2011-06-29 08:54:28 UTC

Then x86 should become one of those selected architectures because there are a number of PCI/PCI-X/PCI-e crypto accelerator add-in cards that use the same API, including the ones from nCipher, Cavium, HP, Oracle, IBM, etc. I don't think your refusal based on arch availability withstands logical scrutiny.

Comment 9 Tomas Mraz 2011-06-29 09:05:13 UTC

But we do not ship the cryptodev-linux kernel module.

Comment 10 Gordan Bobic 2011-06-29 16:43:33 UTC

Not in the kernel package, but I see no reason why a dkms package for it couldn't be made available. Is it not better to include support for it in openssl and not use it than to exclude it and force people to things themselves the hard way?