[Openswan dev] ocf debian

[Harald Jenny]

On Mon, Dec 20, 2010 at 04:23:48AM -0500, Paul Wouters wrote:
> On Mon, 20 Dec 2010, Harald Jenny wrote:
> 
> >>Yes it does. Though at this moment, since OCF is not standard in the kernel (and prob
> >>never will be because of the alternative but less developed "acrypto"), the user
> >>has explicitely decided to want ocf. So it makes sense.
> >
> >Not userfriendly and may really piss off admins. I as an admin may decide to
> >install OCF on a machine for later testing (at my decision) but the next time I
> >restart openswan they get loaded anyway (which may result in undesired
> >behavior).
> 
> 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 - with a config file option this
would be definitly easier (one could even discuss if it should be set to
ocf=off per default).

> 
> >>You said "loads cryptodev", that is a side effect.
> >
> >Sorry what I meant was: run internal "ipsec --versioncode" - when we detect
> >pluto was compiled with OCF support then load cryptodev (I'm personally not a
> >fan of modifying ipsec scripts as they will be overwritten when the next
> >version gets installed.
> 
> 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...

> 
> >>_startklips already does that now, except for the specific hardware modules. I'm not
> >>sure if it would make sense to try all the hardware that hardly anyone would have.
> >>Though I'm willing to do something that looks into "lspci" and loads whatever it
> >>finds. But then someone needs to tell me the pci identifiers for these hardware
> >>cards, since I don't have many of them.
> >
> >Hmmm sorry from the git log entry I thought you always try to load cryptoloop
> >regardless if KLIPS is compiled with it or OCF is installed.
> 
> We only probe for cryptosoft in _startklips, meaning you have set protostack=klips|mast.

Ok but this nevertheless means that if KLIPS is compiled with OCF it gets used,
wether I want it or not?

> This is done regardless of compile time options for userland/klips.

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?

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

> I do agree we can load cryptodev if userland OCF support was enabled, and
> will add that.

Ok

> 
> Paul

Kind regards
Harald