ocf-linux-users

Re: [Ocf-linux-users] OCF inbuilt and 2.6.27

[<inf...@he...>]

Hello

I am sorry that just joining the mailing list and immediately sending a question is probably a great faux pas, and I want to apologize for that.

My problem is related to the moving of OCF into the kernel with the 2.6.27 release.
Before I was running 2.6.24-4 from the Slackware repository with the OCF 20080917 framework, but I was really excited about the OCF framework moving into the kernel with the 2.6.27 release.

My problem is strange, but is the following... (please bare with me here, it might take a few lines to explain this)

After upgrading my development server to 2.6.27 with the inbuilt support for the HiFn 7956HXL luks have stopped working.
To clarify what I mean by this. I can unlock my luks volumes just fine, but when the time comes to mount them, the mount command just hangs there forever, and I am forced to kill it.

I have tried the 2.6.27-7 from the Slackware repository, as well as the 2.6.28-7 from kernel.org, and the same behavior can be experienced. However, if I disable the HiFn card completely from the kernel I can mount my luks partitions just fine again.

Checking /proc/crypto I see that the HiFn modules are marked with a priority of 300 and the kernel inbuilt modules are marked with a priority of 100, and according to my broken logic (based on Cisco here) this should mean the kernel inbuilt modules should be used in preference for AES rather than my HiFn card.

I mainly bought this card because I am doing some development where I need literally shitloads of random entropy, and until the built in drivers I had no problems getting this, and the built in framework seems to give me even better RNG throughput, and I am really thankful for that! Don't get me wrong!

But is there any way of making both my HiFn card's RNG work as well as luks with a 2.6.27 kernel? Is anyone else but me experiencing the same issues with AES, HiFn, 2.6.27 and luks?

Best Regards,
Frode Moseng

 




"A word to the wise is infuriating." 
Hunter S. Thompson


-- 
_______________________________________________
Get your free email from http://europe.sanriotown.com

Re: [Ocf-linux-users] OCF inbuilt and 2.6.27

[David M. <Dav...@se...>]

Jivin inf...@he... lays it down ...
> Hello
> 
> I am sorry that just joining the mailing list and immediately sending a
> question is probably a great faux pas, and I want to apologize for that.

No need.

> My problem is related to the moving of OCF into the kernel with the 2.6.27 release.
> Before I was running 2.6.24-4 from the Slackware repository with the OCF
> 20080917 framework, but I was really excited about the OCF framework moving
> into the kernel with the 2.6.27 release.

OCF is not moving into the kernel,  not ever.  The licensing was one of
the major stumbing blocks.

My guess is that you are looking at the new cryptoAPI stuff in the
kernel which has hifn/talitos and other drivers.

> My problem is strange, but is the following... (please bare with me here,
> it might take a few lines to explain this)
> 
> After upgrading my development server to 2.6.27 with the inbuilt support for
> the HiFn 7956HXL luks have stopped working.
> To clarify what I mean by this. I can unlock my luks volumes just fine, but
> when the time comes to mount them, the mount command just hangs there
> forever, and I am forced to kill it.
> 
> I have tried the 2.6.27-7 from the Slackware repository, as well as the
> 2.6.28-7 from kernel.org, and the same behavior can be experienced. However,
> if I disable the HiFn card completely from the kernel I can mount my luks
> partitions just fine again.
> 
> Checking /proc/crypto I see that the HiFn modules are marked with a
> priority of 300 and the kernel inbuilt modules are marked with a priority
> of 100, and according to my broken logic (based on Cisco here) this should
> mean the kernel inbuilt modules should be used in preference for AES rather
> than my HiFn card.
> 
> I mainly bought this card because I am doing some development where I need
> literally shitloads of random entropy, and until the built in drivers I had
> no problems getting this, and the built in framework seems to give me even
> better RNG throughput, and I am really thankful for that! Don't get me wrong!
> 
> But is there any way of making both my HiFn card's RNG work as well as
> luks with a 2.6.27 kernel? Is anyone else but me experiencing the same
> issues with AES, HiFn, 2.6.27 and luks?

My guess is that previously you were using OCF for RNG entropy and not much
else,  while your luks was using software.

You get back to what you had by patching your kernel for OCF just as you
did in the past (although you need some patched posted to this list for
2.6.27), and disabling the kernel hifn driver.

Not sure if the RNG support is currently done by the in-kernel hifn
driver or not,  you would need to check the source.  OCF will still
support it as it always has, provising the kernel is appropriately
patched for OCF ;-)

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

Re: [Ocf-linux-users] OCF inbuilt and 2.6.27

[Daniel M. <da...@da...>]

On Mon, 16 Mar 2009 16:41:12 +1000 David McCullough wrote:

> OCF is not moving into the kernel,  not ever.  The licensing was one
> of the major stumbing blocks.

I have just checked kernel 2.6.28.7 and I found (native) drivers for

- VIA's Padlock
- AMD's Geode AES engine
- Intel's IXP4xx NPE-C
- Freescale's Integrated Security Engine (talitos)
- HIFN 795x crypto accelerator

That's definitely more than two years ago.

I am now asking myself why not write native Linux drivers instead of
OCF modules and use the cryptodev (/dev/crypto) interface only? I have
read the OCF documentation and I know that David would like other OS
projects (e.g. OpenBSD or FreeBSD) to benefit from new/improved
drivers. I can hardly imagine that new drivers can be adopted without
porting efforts.

I myself would rather write a native driver and distribute it with
dual license (GPL/BSD). The only reason I didn't managed it yet was the
lack of documentation of Linux's async crypto API ;-)

A native driver could be used for
- kernel IPSec
- luks/dm-crypt
- ..

The cryptodev/cryptosoft interface is still needed for user space
applications such as OpenSSL. If those two parts where GPL licensed 
the acceptance for kernel inclusion could raise. Or do I forget
something important here?

Just my two cents worth :-)

bye,
Daniel

-- 
Daniel Mueller          http://www.danm.de
Berlin, Germany         OpenPGP: F9F982C1

Re: [Ocf-linux-users] OCF inbuilt and 2.6.27

[David M. <Dav...@se...>]

Jivin Daniel Mueller lays it down ...
> On Mon, 16 Mar 2009 16:41:12 +1000 David McCullough wrote:
> 
> > OCF is not moving into the kernel,  not ever.  The licensing was one
> > of the major stumbing blocks.
> 
> I have just checked kernel 2.6.28.7 and I found (native) drivers for
> 
> - VIA's Padlock
> - AMD's Geode AES engine
> - Intel's IXP4xx NPE-C
> - Freescale's Integrated Security Engine (talitos)
> - HIFN 795x crypto accelerator
> 
> That's definitely more than two years ago.

Absolutely,  and the crypto guys a fixing stuff all the time.  A
serialised async ipsec patch was posted today.  All of this native
linux crypto is slowly coming together.

> I am now asking myself why not write native Linux drivers instead of
> OCF modules and use the cryptodev (/dev/crypto) interface only?

There is nothing wrong with that approach at all,  and if linux is your
focus,  and you would like your work to be mainlined, thats the only
approach to chose.

> I have
> read the OCF documentation and I know that David would like other OS
> projects (e.g. OpenBSD or FreeBSD) to benefit from new/improved
> drivers.

There were lots of reasons OCF never had a chance to make it into the
kernel.  Firstly, the licensing,  and since I reused so much of the OCF
code there was no way I could change the license without permission from
all the listed authors.  Understandably a number of them refused to
allow it to be released under a Dual BSD/GPL license.  So it had to
stick with BSD.

> I can hardly imagine that new drivers can be adopted without
> porting efforts.

Yes,  but the porting is purely at the HW level,  all the "API" bits
stay the same.

> I myself would rather write a native driver and distribute it with
> dual license (GPL/BSD). The only reason I didn't managed it yet was the
> lack of documentation of Linux's async crypto API ;-)

Use the talitos driver as an example.  From what I have seen it should
be fairly easy to follow.

> A native driver could be used for
> - kernel IPSec
> - luks/dm-crypt
> - ..
> 
> The cryptodev/cryptosoft interface is still needed for user space
> applications such as OpenSSL. If those two parts where GPL licensed 
> the acceptance for kernel inclusion could raise. Or do I forget
> something important here?

There have already be patches posted for a kernel crypto API user
interface,  however,  there is a tendancy to avoid it,  even if it isn't
OCF.  Just the linux-crypto mailing list or look through the archives
for all the OCF and other user mode interface discussions.

Current thinking is that they would rather move the bulk crypto into the
kernel as a full SSL socket type than use an user-kernel API to do the
crypto.  This is good in that it gives you really high performance SSL
connections,  downside is that you have to wait for it to arrive ;-)

In the interim,  using cryptosoft and cryptodev with native kernel
crypto drivers is an easy way to keep working while they sort it out,

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org

Re: [Ocf-linux-users] OCF inbuilt and 2.6.27

[Daniel M. <da...@da...>]

On Tue, 17 Mar 2009 10:38:47 +1000 David McCullough wrote:

> [.. snip ..]
> Use the talitos driver as an example.  From what I have seen it should
> be fairly easy to follow.

Thanks for all this information. I'll have a look at it. 

BTW: the ubsec_ssb OCF driver is now part of OpenWRT [1]. I got
positive feedback from a few people. The only application(s) that can
be accelerated at the moment is libopenssl with OpenSSH. 

I am still having problems with OpenSWAN. Unfortunately packets that
need to be forwarded from one network (e.g. LAN1) to another network
(e.g. Wifi) are not 32bit memory aligned. So in-place
encryption/decryption does not work here (HW requires 32bit aligned
memory for its output data buffer). I couldn't figure out why this
happens - maybe it's the network(-switch) driver, that uses VLAN tags.
If I were allowed to use a different (aligned) memory address for the
output data I could extend the driver to work like this.

Driver details:
Hardware: bcm5365p (IPSec core)
Platform: MIPS (little endian)
Device: Asus WL500gP
Bus: SSB (Sonic Silicon Backplane)
Implemented algos: (3)DES, AES (128,192,256), MD5-HMAC, SHA-1-HMAC
Original BSD driver source: OpenBSD (ubsec x86 PCI (3)DES accelerator)

[1] https://dev.openwrt.org/browser/trunk/package/ubsec_ssb/src

bye,
Daniel
-- 
Daniel Mueller          http://www.danm.de
Berlin, Germany         OpenPGP: F9F982C1

Re: [Ocf-linux-users] OCF inbuilt and 2.6.27

[David M. <Dav...@se...>]

Jivin Daniel Mueller lays it down ...
> On Tue, 17 Mar 2009 10:38:47 +1000 David McCullough wrote:
> 
> > [.. snip ..]
> > Use the talitos driver as an example.  From what I have seen it should
> > be fairly easy to follow.
> 
> Thanks for all this information. I'll have a look at it. 
> 
> BTW: the ubsec_ssb OCF driver is now part of OpenWRT [1]. I got


Did you want to send in a copy to include in ocf-linux  ?

> positive feedback from a few people. The only application(s) that can
> be accelerated at the moment is libopenssl with OpenSSH. 
> 
> I am still having problems with OpenSWAN. Unfortunately packets that
> need to be forwarded from one network (e.g. LAN1) to another network
> (e.g. Wifi) are not 32bit memory aligned. So in-place
> encryption/decryption does not work here (HW requires 32bit aligned
> memory for its output data buffer). I couldn't figure out why this
> happens - maybe it's the network(-switch) driver, that uses VLAN tags.
> If I were allowed to use a different (aligned) memory address for the
> output data I could extend the driver to work like this.

You could add a local buffer to each session in your driver,  and,  if
the request was unaligned, output to it and copy back when done.

On these slow CPU's a memcpy of a 1000 bytes is still much faster than
the crypto op.  That would at least get you working transparently and
allow you to use it for openswan ;-)

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org