[Openswan dev] ocf debian
harald at a-little-linux-box.at
Mon Dec 20 04:55:12 EST 2010
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
> 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
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
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.
More information about the Dev