[Openswan dev] ocf debian

[Harald Jenny]

On Fri, Dec 17, 2010 at 08:14:10AM +1000, David McCullough wrote:
> 
> Jivin Harald Jenny lays it down ...
> > On Thu, Dec 16, 2010 at 02:51:39PM -0500, Paul Wouters wrote:
> > > On Thu, 16 Dec 2010, Harald Jenny wrote:
> > > 
> > > >>>Sounds like a very good idea - but must it even be made a compile time option
> > > >>>then for KLIPS? I guess it would rather call for two options like protostack,
> > > >>>namely cryptstack and hashstack, with values "built-in" (both crypto and hash,
> > > >>>default value and fallback), "ocf" (both crypto and hash) and "cryptoapi"
> > > >>>(currently only crypto). How about this?
> > > >>
> > > >>The big issue is that OCF requires us to link to openssl,
> > > >
> > > >For userspace that may be true, but for kernel space?
> > > 
> > > Oh sorry. Right. Currently (according to David) if OCF and CryptoAPI support
> > > are enabled in KLIPS, then first OCF is attempted, then CryptoAPI, then KLIPS
> > > native code. I have not verified if this is so - if it is the compiler #warning
> > > statements are misleading.
> > 
> > Well I think we should test this - the order would be ok for me as OCF could
> > only be used when the module is present (which could be preloaded).
> > 
> > > 
> > > I'm not sure what happens for ciphers that one does not support. For instance if
> > > you pick esp=twofish, will it use CryptoAPI (the only place that supports it)
> > 
> > I would guess no, therefore the ipsec.conf options would make sense.
> 
> 
> Its a fall through mechanism,  so you can have some tunnels using OCF while
> others are using cryptoapi and other are using built in.

Ok

> 
> As long as the algorithm is "registered" by one the the crypto levels you
> will be able to use it.

Sounds good

> 
> I reguarly remove OCF HW drivers (so there are none) and fall back to
> cryptoapi.

Ah ok

> 
> > > I am not sure if making these available to the user makes much sense.
> > 
> > To be nitpicking we could also say the same about protostack - I think it's
> > rather targeted towards the expert than the normal user.
> > 
> > > We would
> > > also like to get rid of KLIPS native crypto code (3des,aes) in favour of the
> > > cryptoapi code,
> > 
> > As soon as some more time appears I want to dig into hashing/compressing with
> > cryptoapi...
> > 
> > > though I think currently would break OCF (as the native crypto
> > > code in cryptoapi does not have OCF support)
> > 
> > Hmmm I thought removing the native code was rather meant as getting rid of the
> > included algos themselves, not the whole code base allowing multiple algo
> > sources.
> > 
> > > and I think the native klips code
> > > might be a few percent faster for 3des/aes (benchmark results might not be up to
> > > date anymore)
> > 
> > With UML we might be able to test ;-).
> > 
> > > 
> > > >>and for instance
> > > >>Red Hat does not allow us to do that because of certification.
> > > >
> > > >Ok sounds reasonable but this would not prevent us from giving users the option
> > > >in ipsec.conf?
> > > 
> > > What informed decisions could a user make not to prefer the faster over the slower
> > > kernel method?
> > 
> > Stability issues for example? I guess cryptoapi has a better testing background
> > on rare arches than linux OCF.
> 
> 
> I would almost say the opposite myself ;-)  OCF has been used primarily in the
> embedded space.  It has more miles on it for HW accel. than crypto api.

Well I rather thought about the big ones not the little ones ;-) - sparc for
example?

> 
> It doesn't have the mainstream awareness,  but it might be on more devices.

Hmmm ok

> 
> 
> > > >>>>Okay, and that's probably the most useful and easest to do. So a dkms without
> > > >>>>userland ocf pacakge. Then change the klips DKMS to require the ocf-dkms.
> > > >>>
> > > >>>Well I would rather call it an option, not a requirements - maybe there are
> > > >>>people out there who don't want to use OCF?
> > > >>
> > > >>David, can we have a module parameter for OCF? eg modprobe ipsec ocf={0,1} ?
> > > >
> > > >I would rather vote for crypt={1,2,3} and hash={1,2|,3(in the future)|}.
> > > 
> > > I'm still not entirely sure what that buys though.
> > 
> > I'm just proposing it, maybe David can also comment on this? On the other hand,
> > I think he told me that when no OCF hardware acceleration is found OCF will use
> > cryptoapi as a fallback, correct? Would this also include hardware acceleration
> > that can be done by cryptoapi but not OCF or only software?
> 
> Yes,  anything crypto API can do OCF can take adavantage of.

May I ask how much performance penality this brings?

> 
> Cheers,
> Davidm

Kind regards
Harald

> 
> -- 
> David McCullough,      david_mccullough at mcafee.com,  Ph:+61 734352815
> McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org