[Openswan dev] ocf debian

[Harald Jenny]

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.

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

> 
> >>>>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?

> 
> Paul

Kind regards
Harald