[Openswan dev] ocf debian

[Paul Wouters]

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?

Correct.

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

Right.

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

Paul