DragonFlyBSD

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

[..]

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

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

Thomas Nikolajsen (via DragonFly issue tracker) schrieb:

Thomas Nikolajsen <thomas.nikolajsen@mail.dk> 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:

1. kldload hifn.ko
2. 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

1. 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

1. 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

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

2010/1/11 Thomas Nikolajsen (via DragonFly issue tracker)
<sinknull@leaf.dragonflybsd.org>:

Thomas Nikolajsen <thomas.nikolajsen@mail.dk> 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

Thomas,

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

Cheers,
Alex Hornung

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

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

On Sat, Jan 23, 2010 at 6:10 PM, Alex Hornung (via DragonFly issue
tracker) <sinknull@leaf.dragonflybsd.org> wrote:

Alex Hornung <ahornung@gmail.com> 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

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

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

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

I assume this bug can be closed?

Peter Avalos <pavalos@theshell.com> added the comment:

I assume this bug can be closed?

Agreed.

Jan

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

Cheers,
Alex