Modify

Opened 10 years ago

Closed 8 years ago

Last modified 4 years ago

#3775 closed enhancement (fixed)

Give the user the possibility to enable cryptodev-support in openssl

Reported by: daniel@… Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version:
Keywords: cryptodev openssl Cc:

Description

It would be nice if I (the user) could choose whether I want /dev/crypto (cryptodev) support in OpenSSL.

Patch attached for: package/openssl/Makefile

Attachments (3)

openssl-opt-cryptodev.patch (1.1 KB) - added by anonymous 10 years ago.
openssl-better.patch (2.1 KB) - added by daniel@… 10 years ago.
Better patch with menu help/description
openssl-2008-11-29.patch (1.8 KB) - added by daniel@… 9 years ago.
Gives the user the possibility to enable cryptodev. Useful when using ubsec_ssb.

Download all attachments as: .zip

Change History (14)

Changed 10 years ago by anonymous

comment:1 follow-up: Changed 10 years ago by anonymous

it doesn't make sense to enable it on platforms without hwcrypto support or disable it on platforms with hwcrypto..

Changed 10 years ago by daniel@…

Better patch with menu help/description

comment:2 in reply to: ↑ 1 Changed 10 years ago by daniel@…

Replying to anonymous:

it doesn't make sense to enable it on platforms without hwcrypto support or disable it on platforms with hwcrypto..

The kernel 2.6.25/26 in Trunk has OCF linux patches. There are a lot of platforms with OCF supported crypto hardware.

  • VIA padlock (ocf-cryptosoft + native kernel driver)
  • hifn (ocf-cryptosoft + native kernel driver or ocf-hifn driver)
  • Asus WL500g (ocf-ubsec_ssb)
  • safenet (ocf-safe driver)
  • ..

comment:3 follow-up: Changed 10 years ago by anonymous

via apdlock isn't generally available, should be x86 specific
safenet, hifn isn't generally available, at best it could be a module (and I bet you didn't check prices for these)
ssb is broadcom specific, again

comment:4 in reply to: ↑ 3 Changed 10 years ago by anonymous

Replying to anonymous:

via apdlock isn't generally available, should be x86 specific

I do not understand. I thought OpenWRT is for x86 as well?

ssb is broadcom specific

OCF is not. That's why I would like to have an option to enable it (it is disabled by default - except for Intel IXP4xx boards). Shouldn't be the user the one who decides which components are compiled in and which are not?

comment:5 follow-up: Changed 10 years ago by kaloz

Both of you have valid points, but

  1. to use padlock, you don't need ocf, as openssl supports it directly, and it's even faster that way (simply engine support needs to be enabled)
  2. ocf doesn't make sense at all on platforms without hw crypto - this means it doesn't make sense on 21 from the 27 targets
  3. you could argue with add-on crypto cards like hifn or safenet - but only a few people have them (and the price of those aren't low at all)

We should also remmeber that OCF (or any other engine support) increases openssl's (already too big) footprint, and not all broadcom cpus feature crypto - this is true for the ixp420 as well, but on that target size isn't that much of an issue as on broadcom (and on x86 it's certainly not an issue).

comment:6 Changed 9 years ago by anonymous

Too difficult for me. I can't get OpenSSL to use cryptodev engine :(

I'll give up for now and maybe try it later again...

Changed 9 years ago by daniel@…

Gives the user the possibility to enable cryptodev. Useful when using ubsec_ssb.

comment:7 Changed 9 years ago by daniel@…

Hello again,

I would ask you to rethink about. Of course, cryptodev support should NOT be enabled by default. However, users that own a device that can be accelerated (e.g. the Asus WL500gP) would be happy to compile their own openssl lib without applying the needed patches by themselves. It is just an additional menu entry "[ ] Force cryptodev support".

Greetings,
Daniel

comment:8 in reply to: ↑ 5 ; follow-up: Changed 9 years ago by KanjiMonster

Replying to kaloz:

Both of you have valid points, but

  1. to use padlock, you don't need ocf, as openssl supports it directly, and it's even faster that way (simply engine support needs to be enabled)
  2. ocf doesn't make sense at all on platforms without hw crypto - this means it doesn't make sense on 21 from the 27 targets
  3. you could argue with add-on crypto cards like hifn or safenet - but only a few people have them (and the price of those aren't low at all)

We should also remmeber that OCF (or any other engine support) increases openssl's (already too big) footprint, and not all broadcom cpus feature crypto - this is true for the ixp420 as well, but on that target size isn't that much of an issue as on broadcom (and on x86 it's certainly not an issue).

Wouldn't it be a solution to treat them as two separate openssl packages, one with and one without ocf-support, both providing "libopenssl" (or whatever the packagename is). That way users can choose which one to install, and the ocf one could additionally depend on targets that do have crypto hw support.

That way it should be possible to have the cake and eat it, too. ;)

comment:9 in reply to: ↑ 8 Changed 9 years ago by anonymous

Replying to KanjiMonster:

Replying to kaloz:

Both of you have valid points, but

  1. to use padlock, you don't need ocf, as openssl supports it directly, and it's even faster that way (simply engine support needs to be enabled)
  2. ocf doesn't make sense at all on platforms without hw crypto - this means it doesn't make sense on 21 from the 27 targets
  3. you could argue with add-on crypto cards like hifn or safenet - but only a few people have them (and the price of those aren't low at all)

We should also remmeber that OCF (or any other engine support) increases openssl's (already too big) footprint, and not all broadcom cpus feature crypto - this is true for the ixp420 as well, but on that target size isn't that much of an issue as on broadcom (and on x86 it's certainly not an issue).

Wouldn't it be a solution to treat them as two separate openssl packages, one with and one without ocf-support, both providing "libopenssl" (or whatever the packagename is). That way users can choose which one to install, and the ocf one could additionally depend on targets that do have crypto hw support.

That way it should be possible to have the cake and eat it, too. ;)

I concur: most routers with hardware accelerated encryption also come with more memory and won't mind the extra memory footprint from ocf-support.

comment:10 Changed 8 years ago by nbd

  • Resolution set to fixed
  • Status changed from new to closed

fixed in r19371

comment:11 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.