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

Tue Oct 11 09:57:01 EDT 2011

Hi David

Thanks for your prompt response. Below are few details that you may be
helpful in solving my crash issue.

1. I am using TI's AM3872 chip based SoC (for some reason TI do not map this
device into any of their OMAP2/OMAP3 classification ). You can find few more
details about thier OCF driver in
following<http://processors.wiki.ti.com/index.php/Installing_AM389x_C6A816x_DM816x_Crypto_Support>
wiki
page.

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.

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
# CONFIG_OCF_SAFE is not set
# CONFIG_OCF_IXP4XX is not set

oot at R3BTS-CP-PFS1.0# cp /home/ipsec.secrets /etc/
root at R3BTS-CP-PFS1.0# cd lib/modules/2.6.37-svn3005/kernel/crypto/ocf/
root at R3BTS-CP-PFS1.0# ls
cryptodev.ko   cryptosoft.ko  ocf.ko
root at R3BTS-CP-PFS1.0# insmod ocf.ko
ocf: module license 'BSD' taints kernel.
Disabling lock debugging due to kernel taint
root at R3BTS-CP-PFS1.0# insmod cryptosoft.ko
root at R3BTS-CP-PFS1.0# sh /home/start_ipsec.sh
ipsec_setup: Stopping Openswan IPsec...
ipsec_setup: stop ordered, but IPsec appears to be already stopped!
ipsec_setup: doing cleanup anyway...
ipsec_setup: Starting Openswan IPsec U2.6.33/K2.6.37-svn3005...
104 "test" #1: STATE_MAIN_I1: initiate
003 "test" #1: ignoring unknown Vendor ID payload [4f456d406b6753464548407f]
003 "test" #1: received Vendor ID payload [Dead Peer Detection]
003 "test" #1: received Vendor ID payload [RFC 3947] method set to=109
106 "test" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "test" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): no NAT
detected
108 "test" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "test" #1: received Vendor ID payload [CAN-IKEv2]
004 "test" #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp2048}
117 "test" #2: STATE_QUICK_I1: initiate
004 "test" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode
{ESP=>0x3e088f38 <0x444a8a6a xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none
DPD=none}
root at R3BTS-CP-PFS1.0# sh /home/start_ipsec.sh
ipsec_setup: Stopping Openswan IPsec...
ipsec_setup: Starting Openswan IPsec U2.6.33/K2.6.37-svn3005...
117 "test" #3: STATE_QUICK_I1: initiate
004 "test" #3: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode
{ESP=>0xb3c2cf68 <0xebc46bcd xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none
DPD=none}
root at R3BTS-CP-PFS1.0# clear

root at R3BTS-CP-PFS1.0# /etc/init.d/ipsec status ------------------->IPSEC
status
IPsec running  - pluto pid: 940
pluto pid 940
2 tunnels up
some eroutes exist
root at R3BTS-CP-PFS1.0# tail -f /var/log/messages &
root at R3BTS-CP-PFS1.0# Jan  1 00:06:19 (none) authpriv.warn pluto[940]:
"test" #2: responding to Quick Mode proposal {msgid:3109c7c4}
Jan  1 00:06:19 (none) authpriv.warn pluto[940]: "test" #2:     us:
10.100.207.232<10.100.207.232>[+S=C]
Jan  1 00:06:19 (none) authpriv.warn pluto[940]: "test" #2:   them:
192.168.11.45<192.168.11.45>[+S=C]
Jan  1 00:06:19 (none) authpriv.warn pluto[940]: "test" #2: transition from
state STATE_QUICK_R0 to state STATE_QUICK_R1
Jan  1 00:06:19 (none) authpriv.warn pluto[940]: "test" #2: STATE_QUICK_R1:
sent QR1, inbound IPsec SA installed, expecting QI2
Jan  1 00:06:19 (none) authpriv.warn pluto[940]: "test" #2: transition from
state STATE_QUICK_R1 to state STATE_QUICK_R2
Jan  1 00:06:19 (none) authpriv.warn pluto[940]: "test" #2: STATE_QUICK_R2:
IPsec SA established tunnel mode {ESP=>0x1e7828f1 <0xc482ffbd
xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none}
Jan  1 00:06:20 (none) authpriv.warn pluto[940]: "test" #3: initiating Quick
Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK {using isakmp#1
msgid:138cc3de proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048}
Jan  1 00:06:20 (none) authpriv.warn pluto[940]: "test" #3: transition from
state STATE_QUICK_I1 to state STATE_QUICK_I2
Jan  1 00:06:20 (none) authpriv.warn pluto[940]: "test" #3: STATE_QUICK_I2:
sent QI2, IPsec SA established tunnel mode {ESP=>0xb3c2cf68 <0xebc46bcd
xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none}

oot at R3BTS-CP-PFS1.0# lsmod  ------------------->loaded modules
cryptosoft 11387 0 - Live 0xbf00c000
ocf 16852 1 cryptosoft, Live 0xbf000000 (P)

root at R3BTS-CP-PFS1.0# ping 192.168.11.45
PING 192.168.11.45 (192.168.11.45): 56 data bytes
64 bytes from 192.168.11.45: seq=0 ttl=64 time=0.967 ms
64 bytes from 192.168.11.45: seq=1 ttl=64 time=0.697 ms
64 bytes from 192.168.11.45: seq=2 ttl=64 time=0.664 ms
64 bytes from 192.168.11.45: seq=3 ttl=64 time=0.652 ms

Hope above information will be useful. Apart from this I have few queries :

a) When I am not using OCF and H/W accelerator which (s/w)crypto library is
used by ipsec for encryption ?

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?

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.

d) I did't get your 'There is no cryptoAPI-->OCF driver,  only the
OCF-->cryptoAPI driver (cryptosoft).' point. Can you elaborate more on it
please.

At last apologies for my late response I was on leave as its
festival season here. Will be prompt in my response in future.

@Paul.

Thanks for adding David into this loop!

-SP

On Thu, Oct 6, 2011 at 10:48 AM, David McCullough <
david_mccullough at mcafee.com> wrote:

>
> Jivin Paul Wouters lays it down ...
> > On Wed, 5 Oct 2011, satpal parmar wrote:
> >
> > > First let??me thank Paul. Only??because??of ??prompt??responses to all
> my queries I was able to??achieve??my ??milestone of run??Openswan (2.6.33)
> on my ARM Soc running
> > > linux 2..6.37 (netkey).
> >
> > Feel free to do a write up on the wiki at http://gsoc.xelerance.com/ :)
> >
> > > After going through mailing lists and google reading ??I came up I
> with??following??queries:??
> > >
> > > 1. Whats best way to go solving problem of????add H/W accelerator
> support for Openswan? No much on??Goggling??on this.
> >
> > I'd say OCF is the way to go, especially if OCF has support for that
> vendor.
>
> Yep,  if they have provided an OCF driver thats the easiest place to start.
>
> > > 2. Should I use OCF or CryptoAPI? From what I
> read??Linux??native??crypto??api do not support H/W accelerators. Do I
> really need any of these? Whats NSS good for?
> > > I know last question is naive!
> >
> > If you built in support for both OCF and CryptoAPI, then KLIPS will first
> try to use OCF and if no hardware is found, use cryptoapi
> >
> > > 3. Is NETKEY??compatible??with OCF? ??If Yes, do I need to recompile my
> openswan with OCF support? If no as this link says, what my best next
> option? KLIPs?
> >
> > Yes, you can use OCF with NETKEY using the "cryptosoft" driver
>
> Ok,  just to be sure you don't mis-interpret that:
>
> 1. You cannot accelerate NETKEY with OCF.  NETKEY uses cryptoAPI.  There is
>   no cryptoAPI-->OCF driver,  only the OCF-->cryptoAPI driver (cryptosoft).
>
> 2. You can use the kernels cryptoAPI drivers (SW and HW) with OCF by using
>   the OCF cryptosoft driver.  This allows OCF and NETkey to use the same
>   crypto drivers (available in newish kernels).
>
>
>
> > > 4. Should openswan (2.6.33) ??+ linux kernel 2.6.37 (netwkey ??and OCF
> support enabled) ??| H/W drivers from vendors combo work ? Anything missing
> or any mismatch
> > > for H?W accelerator support.
> >
> > It should work, but a lot depend on the vendor, and if they supply
> non-free code then it might be a little outdated.
> >
> > > 5. What Flags/compiler option/??libraries I MAY need to enable to
> make??things??work fine.????
> >
> > For kernel OCF mode, you need no special flags/options. Just make the OCF
> modules for your kernel.
> > For KLIPS you need to enable CONFIG_KLIPS_OCF.
> > For userland OCF (eg for IKE), you need openssl installed and enable
> HAVE_OCF=true
> >
> > I don't see anything that seems to relate to OCF or KLIPS or NETKEY in
> the below crash.
> > Perhaps David can shed more light on that.
>
> Hmm,  other than the fact that it seems to be DMA related,  and any OCF
> driver worth having will be using DMA.
>
> It might be useful to know your platform,  what crypto driver (the vendor
> OCF driver) you are using.
>
> What sort of load are you running when this fails.  Are you even using OCF
> ?
> If you unload the vendor OCF driver and just use cryptosoft to do crypto do
> you get the crash ?
>
> Cheers,
> Davidm
>
> > > root at R3BTS-CP-PFS1.0# ping 192.168.11.45
> > > PING 192.168.11.Unable to handle kernel paging request at virtual
> address 70207000
> > > 45 (192.168.11.4pgd = ef8e4000
> > > 5): 56 data byte[70207000] *pgd=00000000s
> > >
> > > Internal error: Oops: 805 [#1]
> > > last sysfs file: /sys/devices/virtual/dmb_gpio/dmb_gpio1/dev
> > > Modules linked in:
> > > CPU: 0 ?? ??Not tainted ??(2.6.37-svn3005 #11)
> > > PC is at v7_dma_clean_range+0x1c/0x34
> > > LR is at dma_cache_maint_page+0x34/0x3c
> > > pc : [<c00446cc>] ?? ??lr : [<c0041854>] ?? ??psr: 00000113
> > > sp : ee8ffea0 ??ip : c0444000 ??fp : ee8ffeac
> > > r10: 00000001 ??r9 : efa480d8 ??r8 : 00000000
> > > r7 : 00000000 ??r6 : 00000001 ??r5 : efa480d8 ??r4 : efa480e8
> > > r3 : 0000003f ??r2 : 00000040 ??r1 : 70207000 ??r0 : 70207000
> > > Flags: nzcv ??IRQs on ??FIQs on ??Mode SVC_32 ??ISA ARM ??Segment user
> > > Control: 10c5387d ??Table: af8e4019 ??DAC: 00000015
> > > Process ping (pid: 657, stack limit = 0xee8fe2e8)
> > > Stack: (0xee8ffea0 to 0xee900000)
> > > fea0: ee8ffec4 ee8ffeb0 c004187c c004182c c0044718 efa48080 ee8ffef4
> ee8ffec8
> > > fec0: c0041b34 c0041868 00000001 00000000 efa4818c eea8cc80 efa4814c
> 00000006
> > > fee0: 00000009 c042fcc0 ee8fff14 ee8ffef8 c0223788 c0041aec efa4818c
> eea8cc80
> > > ff00: 00000001 efa4814c ee8fff34 ee8fff18 c0223fe0 c02236dc 00000000
> 00000100
> > > ff20: 00000018 00000001 ee8fff4c ee8fff38 c005ee58 c0223f24 ee8fe000
> 00000100
> > > ff40: ee8fff84 ee8fff50 c005f44c c005edf4 ee8fff6c ee8fff60 c00489dc
> 00000074
> > > ff60: 00000000 0000000e 0002e9ec 00000000 ee8fe000 001ecc60 ee8fff94
> ee8fff88
> > > ff80: c005f51c c005f3d8 ee8fffac ee8fff98 c0031080 c005f4e0 ffffffff
> fa200000
> > > ffa0: 00000000 ee8fffb0 c02f27bc c003100c 0000000e 0002e9ec 00000000
> 00000000
> > > ffc0: 00000040 00000001 0000000e 0002e9ec 00000000 bec6ce64 001ecc60
> bec6ce64
> > > ffe0: 0002e9ec bec6ca40 0002e914 000ed420 80000010 ffffffff 92e25cdc
> 09e80cd2
> > > Backtrace:??
> > > [<c0041820>] (dma_cache_maint_page+0x0/0x3c) from [<c004187c>]
> (___dma_page_cpu_to_dev+0x20/0x2c)
> > > [<c004185c>] (___dma_page_cpu_to_dev+0x0/0x2c) from [<c0041b34>]
> (dma_map_sg+0x54/0xf4)
> > > [<c0041ae0>] (dma_map_sg+0x0/0xf4) from [<c0223788>]
> (nss_sham_update_cdma_start+0xb8/0x120)
> > > [<c02236d0>] (nss_sham_update_cdma_start+0x0/0x120) from [<c0223fe0>]
> (nss_sham_done_task+0xc8/0x108)
> > > ??r7:efa4814c r6:00000001 r5:eea8cc80 r4:efa4818c
> > > [<c0223f18>] (nss_sham_done_task+0x0/0x108) from [<c005ee58>]
> (tasklet_action+0x70/0xc0)
> > > ??r7:00000001 r6:00000018 r5:00000100 r4:00000000
> > > [<c005ede8>] (tasklet_action+0x0/0xc0) from [<c005f44c>]
> (__do_softirq+0x80/0x108)
> > > ??r5:00000100 r4:ee8fe000
> > > [<c005f3cc>] (__do_softirq+0x0/0x108) from [<c005f51c>]
> (irq_exit+0x48/0x94)
> > > [<c005f4d4>] (irq_exit+0x0/0x94) from [<c0031080>]
> (asm_do_IRQ+0x80/0xa0)
> > > [<c0031000>] (asm_do_IRQ+0x0/0xa0) from [<c02f27bc>]
> (__irq_usr+0x3c/0xa0)
> > > Exception stack(0xee8fffb0 to 0xee8ffff8)
> > > ffa0: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0000000e
> 0002e9ec 00000000 00000000
> > > ffc0: 00000040 00000001 0000000e 0002e9ec 00000000 bec6ce64 001ecc60
> bec6ce64
> > > ffe0: 0002e9ec bec6ca40 0002e914 000ed420 80000010 ffffffff
> > > ??r5:fa200000 r4:ffffffff
> > > Code: e3a02004 e1a02312 e2423001 e1c00003 (ee070f3a)??
> > > ---[ end trace 70e1f34cfd579ce9 ]---
> > > Kernel panic - not syncing: Fatal exception in interrupt
> > > Backtrace:??
> > > [<c003fb44>] (dump_backtrace+0x0/0x110) from [<c02f0564>]
> (dump_stack+0x18/0x1c)
> > > ??r7:c00446d0 r6:ee8ffce7 r5:c00446ce r4:c040f390
> > > [<c02f054c>] (dump_stack+0x0/0x1c) from [<c02f05c8>] (panic+0x60/0x17c)
> > > [<c02f0568>] (panic+0x0/0x17c) from [<c003fed8>] (die+0x284/0x2d8)
> > > ??r3:00000100 r2:c0420b42 r1:00000000 r0:c038591e
> > > [<c003fc54>] (die+0x0/0x2d8) from [<c0042384>]
> (__do_kernel_fault+0x6c/0x8c)
> > > [<c0042318>] (__do_kernel_fault+0x0/0x8c) from [<c02f4594>]
> (do_page_fault+0x1f0/0x20c)
> > > ??r9:00000805 r8:70207000 r7:ee946180 r6:e57178c0 r5:ee8ffe58
> > > r4:c03e4518
> > > [<c02f43a4>] (do_page_fault+0x0/0x20c) from [<c02f45d4>]
> (do_translation_fault+0x24/0xa8)
> > > [<c02f45b0>] (do_translation_fault+0x0/0xa8) from [<c00312a4>]
> (do_DataAbort+0x3c/0x9c)
> > > ??r7:ee8ffe58 r6:00000805 r5:c03e4568 r4:c03e4518
> > > [<c0031268>] (do_DataAbort+0x0/0x9c) from [<c02f256c>]
> (__dabt_svc+0x4c/0x60)
> > > Exception stack(0xee8ffe58 to 0xee8ffea0)
> > > fe40: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
> ?? ?? ?? ?? ?? 70207000 70207000
> > > fe60: 00000040 0000003f efa480e8 efa480d8 00000001 00000000 00000000
> efa480d8
> > > fe80: 00000001 ee8ffeac c0444000 ee8ffea0 c0041854 c00446cc 00000113
> ffffffff
> > > ??r8:00000000 r7:00000000 r6:00000001 r5:ee8ffe8c r4:ffffffff
> > > [<c0041820>] (dma_cache_maint_page+0x0/0x3c) from [<c004187c>]
> (___dma_page_cpu_to_dev+0x20/0x2c)
> > > [<c004185c>] (___dma_page_cpu_to_dev+0x0/0x2c) from [<c0041b34>]
> (dma_map_sg+0x54/0xf4)
> > > [<c0041ae0>] (dma_map_sg+0x0/0xf4) from [<c0223788>]
> (nss_sham_update_cdma_start+0xb8/0x120)
> > > [<c02236d0>] (nss_sham_update_cdma_start+0x0/0x120) from [<c0223fe0>]
> (nss_sham_done_task+0xc8/0x108)
> > > ??r7:efa4814c r6:00000001 r5:eea8cc80 r4:efa4818c
> > > [<c0223f18>] (nss_sham_done_task+0x0/0x108) from [<c005ee58>]
> (tasklet_action+0x70/0xc0)
> > > ??r7:00000001 r6:00000018 r5:00000100 r4:00000000
> > > [<c005ede8>] (tasklet_action+0x0/0xc0) from [<c005f44c>]
> (__do_softirq+0x80/0x108)
> > > ??r5:00000100 r4:ee8fe000
> > > [<c005f3cc>] (__do_softirq+0x0/0x108) from [<c005f51c>]
> (irq_exit+0x48/0x94)
> > > [<c005f4d4>] (irq_exit+0x0/0x94) from [<c0031080>]
> (asm_do_IRQ+0x80/0xa0)
> > > [<c0031000>] (asm_do_IRQ+0x0/0xa0) from [<c02f27bc>]
> (__irq_usr+0x3c/0xa0)
> > > Exception stack(0xee8fffb0 to 0xee8ffff8)
> > > ffa0: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 0000000e
> 0002e9ec 00000000 00000000
> > > ffc0: 00000040 00000001 0000000e 0002e9ec 00000000 bec6ce64 001ecc60
> bec6ce64
> > > ffe0: 0002e9ec bec6ca40 0002e914 000ed420 80000010 ffffffff
> > > ??r5:fa200000 r4:ffffffff
> > >
> > >
> > >
> > >
> > >
> >
> >
>
> --
> David McCullough,      david_mccullough at mcafee.com,  Ph:+61 734352815
> McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20111011/1e757a38/attachment-0001.html 