[Openswan Users] Netkey + Openswan + OCF && H/W accelerators drivers == kernel crash/panic

[David McCullough]

Jivin Paul Wouters lays it down ...
> On Tue, 11 Oct 2011, satpal parmar wrote:
> 
> > 2. Ping is first thing I am doing after boot up. So no load on CPU of any kind. Ping works fine??without
> > OCF (and cryptosoft, cryptodev) and H/W driver. In fact I am able to ping with OCF + cryptosoft (see
> > log??below). Only when I enable H/W??accelerator support ping is crashing.????So one may??conclude??driver is
> > the culprit. But I am able to do standalone testing of H/W??accelerators using drivers, cryptodev????and
> > cryptotest as mentioned in wiki entry. So my doubt is if the??interface for??ipsec stack (NETKEY in my
> > case) is consistent with h/w driver I am using. I am not very confident of my understanding of ipsec
> > (netkey) + OCF + h/w driver??intersection??and interfaces.??
> 
> Are you saying it works without cryptodev but not with cryptodev?

No they are saying it works with cryptodev (using cryptotest) but not with
openswan.

This means the crypto driver is function when used in this context.

> cryptodev is the /dev/crypto userland driver to accelerate userland
> crypto, and has nothing to do with the OCF kernel accelerated crypto (kinda)

Thats right,  but it uses the HW driver at the end of the day.  This shows
that in the cryptodev context the driver is functional.

Unfortunately cryptodev in this case is a single threaded application with
no other networking/HW/interrupts involved. Using cryptotest is a super
simple test when compared with the usage you will see from the network
stack  + openswan + OCF.

> > 3. I am not sure if I correctly??understand??what you mean when you said I am using OCF or not. I think I
> > am using it correctly as mention in TI wiki entry. Here is snippet from my config file and log from
> > board??
> > 
> > # OCF Configuration
> > #
> > CONFIG_OCF_OCF=m
> > # CONFIG_OCF_RANDOMHARVEST is not set
> > CONFIG_OCF_CRYPTODEV=m
> > CONFIG_OCF_CRYPTOSOFT=m
> 
> Note that if you need CONFIG_OCF_CRYPTODEV, the patch also patches other
> parts of the linux
> tree. That is, you cannot just have the CONFIG_OCF_CRYPTODEV as a module.

The approach by the wiki entry looks ok.  cryptodev is not the problem here
so it doesn't really matter.

> > a) When I am not using OCF and H/W accelerator which (s/w)crypto??library??is used by ipsec
> > for??encryption???
> 
> Two answers. for the kernel, either KLIPS (via cryptoapi or when not found via native crypto)
> For the userland, openswan uses either NSS (no OCF support AFAIK) or native/openssl (with OCF
> support).

Userspace also has its own implementation I think,  lib/libcrypto ?
SO its NSS (if enabled),  lib/libcrypto/liboswcrypto/cryptodev.c+cryptodev
(if OCF is available) or its own built in crypto.

openssl is needed for OCF use as the two share a lot (types etc) and I think
some conversion functions.

> > b) When we have support of both cryptosoft (software emulation of H/W??accelerators)????and
> > H/W??accelerators (drivers ) how IPsec choose which one to use? Is it a good practice? Do we have any
> > reason to do that?
> 
> I believe the HW takes precedence, but I know in the past that was not always the case.


Correct,  openswan (klips) will use HW accelerators in preference to
cryptosoft.  cryptosoft will use async algs (usually linux native crypto HW
drivers) in preference to synchronous algs (usually software).

So at all points HW is preferred.


> But when there is no klips, it has to go via cryptosoft to netkey to the
> hardware using native
> acceleration, not OCF, if I'm not mistaken.


Sort of,  without klips,  you are using netkey,  which uses cryptoAPI (the
kernels native crypto library).

If you are using klips and have OCF loaded,  then you may be using an OCF
driver or cryptosoft,  or,  you may fall back to cryptoAPI or openswan
native depending on what is loaded and what algs. the various drivers
support.

So the most complex case is with OCF and an OCF HW driver loaded and OCF
support in openswan.  The decision looks like:

   1. Ask OCF if it can do XYZ
      a) OCF checks each driver HW driver to see if it does XYZ - yes, use OCF
      b) OCF checks each driver to see if it does XYZ - yes, use OCF
         (cryptosoft will be probed here,  it will check if any cryptoAPI
          support for XYZ exists,  and if so,  use that and claim support).

   2. Ask cryptoAPI if it can do XYZ - yes, use cryptoAPI

   3. See if openswans native crypto can do XYZ - yes, use native crypto

   4. Fail setup

So thats pretty much the decision,  depending on what options you use to
build openswan,  steps 1, 2 or 3 may be present or absent.  If they are
absent,  you skip to the next number ;-)

> > c) Do I need cryptosoft or cryptodev when I am using h/w acclerators? AFAIU I do not need cryptosoft
> > (why use s/w emulation when i have h/w !). But not sure??about??cryptodev if it is used by OCF ??to
> > provide interface to IPsec stack.??
> 
> cryptosoft is used for accelerating kernel crypto (most important - many packets means much crypto)
> cryptodev is used to accelerate userland crypto (IPsec IKE) which per tunnel requires a few crypto
> operations per hour, so not *that* important. (in fact, having a good entropy device for DiffieHellman
> is probably more important for speed then the HW acceleration for IKE in userland)

If you have an OCF driver,  then you only really need OCF + that driver to
make ipsec tunnels goes fast.

cryptosoft is the backup OCF driver that uses the kernels cryptoAPI to do
the crypto processing.  Thats fine if you have an SMP system (OCF can spread
it's processing across multiple CPU's),  or if you have linux cryptoAPI
support for your HW.  Other wise they are not really needed and you can just
fall through to steps 2/3 above.

cryptodev allows user space to use your HW crypto.  There is no reason to
load cryptodev unless you have crypto HW with drivers (with OCF or cryptoAPI).

If you have HW,  the only real benefit of cryptodev is CPU usage.  It will
allow your applications to do crypto without using any noticable CPU.  So
unless you are busy doing lots of other things and need the CPU,  cryptodev
is of little benefit.  The reason for this is that copying data from user
space into kernel space and back is expensive, so you do not get the fast
processing you get in the kernel,  so that only benefit is that the crypto
load is not placed on the CPU but instead on the crypto HW.  This allows
your CPU to do other things in user/kernel space while you wait for the
crypto to finish.

Hopefully that hasn't confused you more :-)

Short answer - you only need OCF + your-HW-crypto-driver loaded,  you
should build openswan with OCF, cryptoAPI and native support to be sure
you have everything covered.

Cheers,
Davidm

-- 
David McCullough,      david_mccullough at mcafee.com,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org