[Openswan dev] ocf debian

Paul Wouters paul at xelerance.com
Mon Dec 20 05:32:12 EST 2010

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.

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

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

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

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


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

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


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


More information about the Dev mailing list