Bug #1638

OpenSSL cryptodev patch

Added by lentferj over 4 years ago. Updated over 2 years ago.

Status:FeedbackStart date:
Priority:NormalDue date:
Assignee:alexh% Done:

0%

Category:-
Target version:-

Description

Attached is a patch to enable cryptodev engine support in OpenSSL on
Dragonfly.

I have tested this to some extend on a System with VIA C7 and padlock
with these results:

bash-4.0# openssl speed -elapsed -evp AES-128-CBC
[...]
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192
bytes
aes-128-cbc 2212.74k 9283.28k 14203.47k 81418.80k
551087.35k

openssl speed -elapsed -evp AES-128-CBC -engine padlock
[...]
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192
bytes
aes-128-cbc 34066.30k 115907.26k 294967.28k 483761.44k
567358.91k

[padlock.ko loaded]
openssl speed -elapsed -evp AES-128-CBC -engine cryptodev
[...]
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192
bytes
aes-128-cbc 2357.93k 8318.06k 36483.88k 124004.00k
620408.51k

[padlock.ko unloaded]
openssl speed -elapsed -evp AES-128-CBC -engine cryptodev
[...]
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192
bytes
aes-128-cbc 4413.40k 4146.96k 3727.17k 4627.12k
4654.53k

cryptodev.patch Magnifier (4.81 KB) lentferj, 01/02/2010 11:24 AM

hifn1.diff Magnifier (21.5 KB) alexh, 01/23/2010 10:10 AM

History

#1 Updated by aoiko over 4 years ago

Jan Lentfer wrote:
> Attached is a patch to enable cryptodev engine support in OpenSSL on
> Dragonfly.

Haven't done any testing, but it looks OK. Should be safe to push in so
it can get wider exposure.

Aggelos

#2 Updated by lentferj over 4 years ago

[..]

I found some irregularities when using padlock.ko and cyrptodev with
openssl. I am desperatly looking for someone who has crypto hardware
other than padlock available and is whiling to do some testing with me.

Jan

#3 Updated by thomas.nikolajsen over 4 years ago

>>Attached is a patch to enable cryptodev engine support in OpenSSL on Dragonfly.
>>I have tested this to some extend on a System with VIA C7 and padlock with these results:
>[..]
>
>I found some irregularities when using padlock.ko and cyrptodev with openssl.
>I am desperatly looking for someone who has crypto hardware other than padlock available
>and is whiling to do some testing with me.

I have hifn(4) supported cards, Hi/fn 7955, will try to get test done tonight.
Should I just use same commands as in you original post?

-thomas

#4 Updated by lentferj over 4 years ago

Thomas Nikolajsen (via DragonFly issue tracker) schrieb:
> Thomas Nikolajsen <> added the comment:
>
>
>>> Attached is a patch to enable cryptodev engine support in OpenSSL on Dragonfly.
>>> I have tested this to some extend on a System with VIA C7 and padlock with these results:
>>>
>> [..]
>>
>> I found some irregularities when using padlock.ko and cyrptodev with openssl.
>> I am desperatly looking for someone who has crypto hardware other than padlock available
>> and is whiling to do some testing with me.
>>
>
> I have hifn(4) supported cards, Hi/fn 7955, will try to get test done tonight.
> Should I just use same commands as in you original post?
>
>

you could run the tests as in my original posts, too, to see if it
brings any benefits.

but I am actually more interested in this:

# kldload hifn.ko
# openssl engine cryptodev -c
(cryptodev) BSD cryptodev engine
[RSA, DSA, DH, AES-128-CBC]
^^^^^^^^^^^^^
this tells you what ciphers openssl thinks are supported
then create or pick some basic ascii file and do

# openssl enc -aes-128-cbc -engine cryptodev -in file -out file.enc1
(choose some cipher that openssl says IS supported by cryptodev engine)

then just look (cat, less, vi, w/e) if the file.enc1 is actually
encrypted. In my case it wasn't (less will tell you it is binary, but if
you open it anyway you can see it is not encrypted).

then

# openssl enc -aes-256-cbc -salt -engine cryptodev -in mbox -out mbox.enc
(choose some cipher that openssl says is NOT supported by cryptodev
engine, this will lead to using software encryption)

then just look if this file is actually encrypted.

Thanks for helping out!

Jan

#5 Updated by thomas.nikolajsen over 4 years ago

I wasn't able to test openssl with hifn(4) acceleration:
hifn(4) seems defunct: loading hifn kernel module,
which seems to work (no error shown),
doesn't bring more capabilities to cryptodev
(openssl engine cryptodev -c), also cryptotest fails.
cryptotest is in /usr/src/tools/tools/crypto;
failure is shown with -v flag (& no perf. output).

Test done in master, after your commit to enable cryptodev in openssl.

HW seems OK: above works as expected in fbsd;
also 'openssl enc' *do* encrypt with cipher supported by hifn(4).

Hope you have idea how to fix this issue with hifn(4)/crypto(9).

I first tried to test on 128MB host (soekris4801),
but loading hifn module fails with contigmalloc error.

-thomas

#6 Updated by alexh over 4 years ago

2010/1/11 Thomas Nikolajsen (via DragonFly issue tracker)
<>:
>
> Thomas Nikolajsen <> added the comment:
>
> I wasn't able to test openssl with hifn(4) acceleration:
> hifn(4) seems defunct: loading hifn kernel module,

That could well be my fault when Sascha and I updated opencrypto.
While I made an effort to get hifn to compile properly, I couldn't
test it due to lack of hardware.
Now that I know that someone actually has this hardware, I'll review
the code over the next 2 days or so and post a patch.

Cheers,
Alex Hornung

#7 Updated by alexh over 4 years ago

Thomas,

could you provide the output of pciconf -lv relevant to your crypto device(s)
please?

Cheers,
Alex Hornung

#8 Updated by thomas.nikolajsen over 4 years ago

It is a soekris vpn1401, pciconf(8) output is:
hifn0@pci0:0:12:0: class=0x0b4000 card=0x00000000 chip=0x002013a3 rev=0x00
hdr=0x00
vendor = 'HI-FN Inc.'
device = '7954/7955 Cryptographic Processor'
class = processor

#9 Updated by alexh over 4 years ago

Thomas,

I've attached a patch which updates hifn to the current FreeBSD status. Your
issue is also addressed, which was probably due to the missing device_get_softc
and also the crypto_copy stuff.

Be aware that there might be some other issue with this update, in particular
with the interrupt handling, although it should be fine.

Could you test it and tell me if it works?

Cheers,
Alex Hornung

#10 Updated by sepherosa over 4 years ago

On Sat, Jan 23, 2010 at 6:10 PM, Alex Hornung (via DragonFly issue
tracker) <> wrote:
>
> Alex Hornung <> added the comment:
>

I just took a brief look at the patch, but I don't think you want to
turn on INTR_MPSAFE for the intr handler, if the intr handler does
non-trivial work (like updating softc). It will be better that you
just leave it as non-mpsafe at the early stage. Same may apply to the
callout (I saw callout_init_mp() is used)

Best Regards,
sephe

#11 Updated by thomas.nikolajsen over 4 years ago

hifn(4) works with this patch.
cryptotest works, and 'openssl enc' also doesn't have plaintext in encoded text.
There is problem: LINT build fails.
Also if hifn(4) is unloaded, then loading it again fails, with message below.

I did hifn(4) test on both amd64 system (only i386; will do x86_64 test),
and on low mem system, soekris 4801 w/ vpn1411 (same pciconf output as vpn1401).

I also did padlock(4) test on Via C7 system, and got same result as below:
'openssl enc' using cipher supported by cryptodev contains plaintext.
This is not the case when using 'openssl enc -engine padlock'.
From above it seems to be a problem in padlock(4).
Also tools/tools/crypto/cryptotest doesn't work with padlock(4).

-thomas
-
hifn0 mem 0xec040000-0xec047fff,0xec048000-0xec049fff,0xec04b000-0xec04bfff irq
11 at device 12.0 on pci0
contigmalloc_map: failed size 262143 low=0 high=ffffffff align=1 boundary=0
flags=00001601
hifn0: cannot alloc dma buffer
device_probe_and_attach: hifn0 attach returned 6

#12 Updated by thomas.nikolajsen over 4 years ago

FYI: last message (msg8088) was garbled a bit on mail from Roundup to submit@:
last part (`kldload hifn' output) was put in separate mail, without subject.

-thomas

#13 Updated by alexh over 4 years ago

So I don't forget about this mess, I'm assigning it to myself.

#14 Updated by pavalos over 3 years ago

I assume this bug can be closed?

#15 Updated by lentferj over 3 years ago

Peter Avalos <> added the comment:
> I assume this bug can be closed?
>

Agreed.

Jan

#16 Updated by alexh over 3 years ago

No, this can't be closed. As you can see below it points out an issue with hifn.

Cheers,
Alex

#17 Updated by alexh over 2 years ago

  • Description updated (diff)
  • Status changed from New to Feedback

Does the hifn(4) unloading/loading issue still happen after Matt's changes to contigmalloc? If so, does it persist even after bumping the amount that is reserved for contigmalloc after finishing boot?

Cheers,
Alex

Also available in: Atom PDF