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

[satpal parmar]

On Fri, Oct 14, 2011 at 9:47 AM, Paul Wouters <paul at xelerance.com> wrote:

> On Fri, 14 Oct 2011, satpal parmar wrote:
>
>  Yes,  if you want openssl (and openssl linked apps) or openswans pluto to
>> use the drivers (no point for openswan in my opinion).
>>
>
> If the device is an embedded system, and the HW driver can deliver entropy
> via OCF,
> then there is a very good reason to use it!

OK. But I think adding OCF just for entropy will too taxing for a embeded
system.

>
>  If you use klips,  OCF is the best way to accelerate it.  If you use
>> netkey
>> then you do not need OCF at all.
>>
>
> netkey does not split 1 IPsec SA over multiple CPU's. When using 1 single
> tunnel
> with over then 1 CPU's worth of crypto, it will actually be faster to use
> KLIPS with OCF and cryptosoft.
>
OK

> You would also need OCF if there is an OCF hardware driver, but no native
> cryptoapi
> or async hardware driver that netkey could use.
>
>
>  > No plans for KLIPS. My kernel is KLIPS virgin.
>>
>> Then you do not need OCF unless you want userspace to use your HW drivers.
>>
>
> Correct.
>
>
>  Well I was not very lucky. I tried pinging after removing OCF completely.
>> Still getting the same crash.
>>
>
> Guess it means it was not OCF. So very lucky :)

I see David smiling :)

>


>  Also,  I may have confused you earlier,  I thought you had an OCF driver
>> for
>> some reason.  I was wrong,  its a cryptoAPI driver that you have and it
>> has
>> very little to do with OCF really, except that OCF can use it via
>> cryptosoft ;-)
>>
>> So we can conclude our discussion as: H/w accelerator drivers I am using
>> are based on 2.6 native crypto API. Since this
>> crypto API is designed to be used with in-kernel IPsec stack  Netkey I do
>> not need anything  extra to glue things.
>> This arrangement should work on its own. They introduce OCF to test it
>> from userspace using Openssl/Cryptotest tool which
>> uses Cryptodev.
>>
>
> Yes.
>
>
>  Cryptosoft do many thing one of them is translation for
>> userland utilities so that they can talk
>> with scatter list based Native Crypto API used to support NETKEY the
>> default IP stack in 2.6 kernel.
>>
>
> You mean "cryptodev" here, not "cryptosoft"?

Well I meant cryptosoft. I maybe wrong. So you mean cryptosoft  only do
emulation?

>
>
>  From my testing we have:
>>
>> 1. cryptotest--->cryptodev--->**cryptosoft--->Native crypto
>> API--->driver--->H/W accelerator path working.
>>
>> 2. Ping--->netkey---->native crypto API---> drivers ----> H/W accelerators
>> path crashing.  Its crashing even when I ping
>> from other machine to this machine.
>>
>
> That's something for the driver writers or the kernel people....
>

I made some progress in my investigation here. It seems there is a bug in
driver (drivers/crypto/nss-sham.c)

static int nss_sham_update_cdma_start(struct nss_sham_dev *dd)
{
        struct nss_sham_reqctx *ctx = ahash_request_ctx(dd->req);
        unsigned int length, final, tail;
        struct scatterlist *sg;

        if (!ctx->total)
                return 0;

        if (ctx->bufcnt || ctx->offset)
       return nss_sham_update_cdma_slow(dd); ---------------------->True for
OCF/cryptodev/crptosoft path.This uses dma_single mapping instead of
scatterlist.But in case of netkey/IPsec this is not true and we hit case

     if (!dma_map_sg(dd->dev, ctx->sg, 1, DMA_TO_DEVICE)) {
                dev_err(dd->dev, "dma_map_sg  error\n");
                return -EINVAL;
 which is scatter list DMA implementation and crashes in the end of this
path (as seen in crash dump). I am yet to explore why we got
two different paths and why it crashing but I think this is the right
direction to investigate.

@David
I know its much to ask but if you can spare some time to see the code and
confirm it would be great help. You can find code
here.<http://processors.wiki.ti.com/index.php/Installing_AM389x_C6A816x_DM816x_Crypto_Support>

Thanks in advance.
SP


> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20111014/5e2b45a6/attachment-0001.html