[Openswan dev] ocf debian

[Harald Jenny]

On Mon, Dec 20, 2010 at 05:32:12AM -0500, Paul Wouters wrote:
> On Mon, 20 Dec 2010, Harald Jenny wrote:
> 
> >>The same situation would occur using a new config setup option "ocf", which would
> >>have the default value of "use when available". So I'm not sure how the admin would
> >>be less "pissed off".
> >
> >Currently when OCF is installed I have no option but to edit the KLIPS startup
> >script to modify the behavior of loading OCF
> 
> You only have to change it if you 1) got OCF capable KLIPS and 2) don't want OCF. This
> should be exceptional.

But if yes this should be configurable not codeable ;-).

> 
> >- with a config file option this
> >would be definitly easier (one could even discuss if it should be set to
> >ocf=off per default).
> 
> Yes, possible if we add a option to the ipsec.ko module. I have no issue with this, and
> then making an ocf "config setup" option - perhaps ocf={none,userland,kernel,all} ?

Well that would be an option and would allow for fast testing without having to
modify anything besides ipsec.conf.

> 
> >>We could change _startklips when compiling with OCF support for userland and load the
> >>cryptodev module. And not do so without OCF support. I'll add that for the next
> >>version.
> >
> >Well the question remains if this should be a compile or runtime option...
> 
> If it is a runtime option, and ocf cryptosoft is loaded, and ocf=none, do you propose we
> unload the ocf cryptosoft that other applications (eg openssl with ocf support) might
> be using? And what about the same for the kernel (though I think klips is now the only
> kernel module that supports OCF, so this might not now be an issue)

Hmmm for me the question is: If I want to use openssl with it but not openswan
how may I achieve this? And yes I know these may be obscure options and they
may never really be used but if they get requested it would be better to have
them already in place and implemented in a nice and clean way, don't you think
so too?

> 
> >Ok but this nevertheless means that if KLIPS is compiled with OCF it gets used,
> >wether I want it or not?
> 
> Yes. You would have to rmmod cryptosoft to disable it. Seeing that disabling should at
> most be a temporary meassure, that might be fine?

On a production server where I may not have the option to install a new module
at will such a temporary measure may easy become pratice (from my experience).

> 
> >Without KLIPS supporting OCF it doesn't do anything except loading an unused
> >module I guess?
> 
> Correct.

Ok

> 
> >>Since KLIPS now does
> >>support checking this value via /sys/module/ipsec/parameters/ocf_available we could
> >>skip trying the modprobe for cryptosoft, but I'm not sure if this is worth the extra
> >>code.
> >
> >Hmmm but on the other hand can we be sure that when we load this module that
> >this does not influence other software?
> 
> We can't, but AFAIK, no other kernel module uses kernel OCF.

But we should also think about possible future use...

> 
> >>Also, it would not solve the reverse problem. If the admin has manually loaded
> >>cryptosoft, should we unload the module to avoid klips using it without the "ocf" config
> >>option and possibly break other software using cryptosoft?
> >
> >No, IMHO in this case KLIPS shouldn't use OCF but this would require supporting
> >such a behavior in the KLIPS kernel module.
> 
> Right.

Ok

> 
> >>
> >>In the end, the current situations is pretty easy and most common - Try using kernel OCF
> >>if available.
> >
> >This is the main difference between our views: For you installing the modules
> >is already the opt-in to use them, for me it is just adding an option. I'm not
> >sure I'm comfortable with this situation for Debian, will talk with Rene what
> >he thinks about it.
> 
> We can look at KLIPS module options, but then we should do it complete and also
> offer to use or not use cryptoapi and inline modes.

For me this would be ok - we may add the following options to KLIPS module:
ocf
cryptoapi
builtin
which would deactivate the corresponding set of algs (crypto/hash/compress).
This could be triggered by algostack= in ipsec.conf which should explicitly
list all the stacks the user wants to use (per default all 3). It's a question
wether the order should matter in this case (setting a preference in the KLIPS
module) or not (if yes the argument to the three options for the module may
reflect the user's choice, like 1,2,3)
For the userspace a ocf=0|1 option should be enough which states if we want to
use OCF when it's compiled in or not (log a warning when we want to activate it
and it's not there).

> 
> Paul

Kind regards
Harald