Bug 706706 - Cryptodev offload engine is not enabled by default
Summary: Cryptodev offload engine is not enabled by default
Alias: None
Product: Fedora
Classification: Fedora
Component: openssl
Version: 13
Hardware: arm9
OS: Linux
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-05-22 12:50 UTC by Gordan Bobic
Modified: 2011-06-29 16:43 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-06-27 11:43:30 UTC
Type: ---

Attachments (Terms of Use)

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):

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

1) /usr/include/crypto/cryptodev.h, provided by 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 \
        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: 

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?

Note You need to log in before you can comment on or make changes to this bug.