FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 06-08-2011, 09:54 AM
Alexander Clouter
 
Default Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin

Package: linux-2.6
Version: 2.6.32-34squeeze1
Severity: normal

Whilst deploying IPsec (with strongswan-ike2) I ran into a complication[1]
that causes mv_cesa to spin the CPU when the system receives an IPsec ESP
packet; it seems to be able to send traffic (before the CPU spin) as a
ICMP Echo request (a la pin) out from the system out is okay, until the
ICMP Reply comes back. The packet never 'arrives' as far as userspace is
concerned and the only way to stop the CPU spinning is a reboot.

The configuration I have been using is:
---- server (Marvell OpenRD) ----
conn %default
keyexchange=ikev2
mobike=no
auto=add

conn soas-v6
left=2001:db8:f00:ba4::1
leftprotoport=tcp/echo
right=%any
authby=secret
type=transport

conn soas-v4
left=192.0.2.1
leftprotoport=tcp/echo
right=%any
authby=secret
type=transport
----
---- client (my x86-filth laptop) ----
conn %default
keyexchange=ikev2
mobike=no
auto=route

conn soas-v6
left=%defaultroute
right=2001:db8:f00:ba4::1
rightprotoport=tcp/echo
authby=secret
type=transport

conn soas-v4
left=%defaultroute
right=192.0.2.1
rightprotoport=tcp/echo
authby=secret
type=transport
----

Noticing that IPsec is doing hardware offloading, I looked to see what has
been happening to mv_cesa.c since v2.6.32[2] and nothing stands out other
than 750052dd where SHA1 is enabled (which was backported into 2.6.32)
and there does not seem to be anything bug fixing wise since.

So I tried disabling SHA1 by tinkering with the server side of the
configuration to add:
----
conn %default
esp=aes-md5
----

Now using md5, things start to work. Looks to me as either SHA1 does
not work with IPsec, or when it is combined with at least AES.

If more information is needed then do get intouch.

Cheers

[1] I seem to not be the only one
http://marc.info/?l=linux-crypto-vger&m=130746635214483&w=2
[2] git log v2.6.32..HEAD drivers/crypto/mv_cesa.c

-- Package-specific info:
** Version:
Linux version 2.6.32-5-kirkwood (Debian 2.6.32-34squeeze1) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Thu May 19 12:56:20 UTC 2011

** Command line:
console=ttyS1,115200 panic=10 ubi.mtd=root kw_openrd_init_uart1=232 root=ubi0:rootfs rootfstype=ubifs rw

** Tainted: C (1024)
* Module from drivers/staging has been loaded.

** Kernel log:
[ 46.358343] NET: Registered protocol family 15
[ 46.372871] alg: No test for cipher_null (cipher_null-generic)
[ 46.378824] alg: No test for ecb(cipher_null) (ecb-cipher_null)
[ 46.384900] alg: No test for digest_null (digest_null-generic)
[ 46.390835] alg: No test for compress_null (compress_null-generic)
[ 47.586948] Initializing XFRM netlink socket
[ 88.324860] alg: No test for authenc(hmac(md5),cbc(aes)) (authenc(hmac(md5-generic),mv-cbc-aes))
[ snipped] ...
[24010.137237] alg: No test for authenc(hmac(sha1),cbc(aes)) (authenc(mv-hmac-sha1,mv-cbc-aes))

** Model information
Processor : Feroceon 88FR131 rev 1 (v5l)
Hardware : Marvell OpenRD Ultimate Board
Revision : 0000

** Loaded modules:
Module Size Used by
xfrm6_mode_tunnel 1474 0
xfrm4_mode_tunnel 1546 0
esp6 4591 0
xfrm6_mode_transport 1300 0
authenc 5940 0
xfrm4_mode_transport 1276 0
xt_multiport 2341 1
xfrm_user 18561 2
xfrm4_tunnel 1407 0
tunnel4 2035 1 xfrm4_tunnel
ipcomp 1698 0
xfrm_ipcomp 3557 1 ipcomp
esp4 4807 0
ah4 3703 0
ctr 3241 0
twofish 7467 0
twofish_common 14498 1 twofish
camellia 21397 0
serpent 21417 0
blowfish 8262 0
cast5 16967 0
des_generic 16617 0
cbc 2313 0
xcbc 2219 0
rmd160 8978 0
sha256_generic 8818 0
crypto_null 2122 0
af_key 32325 0
sd_mod 31340 1
crc_t10dif 1106 1 sd_mod
crc32c 2562 4
ib_iser 25394 0
rdma_cm 22074 1 ib_iser
ib_cm 34755 1 rdma_cm
iw_cm 6685 1 rdma_cm
ib_sa 16138 2 rdma_cm,ib_cm
ib_mad 33182 2 ib_cm,ib_sa
ib_core 40421 6 ib_iser,rdma_cm,ib_cm,iw_cm,ib_sa,ib_mad
ib_addr 4427 1 rdma_cm
iscsi_tcp 7907 2
libiscsi_tcp 11547 1 iscsi_tcp
libiscsi 28804 3 ib_iser,iscsi_tcp,libiscsi_tcp
scsi_transport_iscsi 25876 4 ib_iser,iscsi_tcp,libiscsi
fuse 51372 3
ip6_tunnel 11756 0
tunnel6 1866 1 ip6_tunnel
bonding 78390 0
ipv6 253910 52 xfrm6_mode_tunnel,esp6,ib_addr,ip6_tunnel,tunnel6, bonding
iptable_nat 4305 1
nf_nat 13025 1 iptable_nat
nf_conntrack_ipv4 10003 3 iptable_nat,nf_nat
nf_conntrack 49371 3 iptable_nat,nf_nat,nf_conntrack_ipv4
nf_defrag_ipv4 945 1 nf_conntrack_ipv4
ipt_REJECT 1935 2
xt_tcpudp 2129 7
iptable_filter 2012 1
ip_tables 9004 2 iptable_nat,iptable_filter
x_tables 10753 5 xt_multiport,iptable_nat,ipt_REJECT,xt_tcpudp,ip_t ables
dm_mod 56643 2
hmac 2475 0
xgifb 205970 0
sata_mv 24406 0
ehci_hcd 36521 0
sha1_generic 1717 0
fb 38994 1 xgifb
libata 137830 1 sata_mv
usbcore 122503 2 ehci_hcd
mv_cesa 9270 0
cfbcopyarea 2577 1 xgifb
cfbimgblt 1721 1 xgifb
scsi_mod 124276 6 sd_mod,ib_iser,iscsi_tcp,libiscsi,scsi_transport_i scsi,libata
aes_generic 32820 1 mv_cesa
mv643xx_eth 22578 0
cfbfillrect 2788 1 xgifb
nls_base 5367 1 usbcore
libphy 14844 1 mv643xx_eth
inet_lro 5060 1 mv643xx_eth

** PCI devices:
not available

** Sound cards:

-- System Information:
Debian Release: 6.0.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 2.6.32-5-kirkwood
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages linux-image-2.6.32-5-kirkwood depends on:
ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy
ii initramfs-tools [linux 0.98.8 tools for generating an initramfs
ii linux-base 2.6.32-34squeeze1 Linux image base package
ii module-init-tools 3.12-1 tools for managing Linux kernel mo

Versions of packages linux-image-2.6.32-5-kirkwood recommends:
pn firmware-linux-free <none> (no description available)
ii uboot-mkimage 0.4 generate kernel image for U-Boot

Versions of packages linux-image-2.6.32-5-kirkwood suggests:
pn fdutils <none> (no description available)
pn linux-doc-2.6.32 <none> (no description available)

Versions of packages linux-image-2.6.32-5-kirkwood is related to:
pn firmware-bnx2 <none> (no description available)
pn firmware-bnx2x <none> (no description available)
pn firmware-ipw2x00 <none> (no description available)
pn firmware-ivtv <none> (no description available)
pn firmware-iwlwifi <none> (no description available)
pn firmware-linux <none> (no description available)
pn firmware-linux-nonfree <none> (no description available)
pn firmware-qlogic <none> (no description available)
pn firmware-ralink <none> (no description available)
pn xen-hypervisor <none> (no description available)

-- debconf information excluded



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110608095458.21646.49915.reportbug@domokun.it.so as.ac.uk">http://lists.debian.org/20110608095458.21646.49915.reportbug@domokun.it.so as.ac.uk
 
Old 06-08-2011, 11:38 AM
Sebastian Andrzej Siewior
 
Default Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin

* Alexander Clouter | 2011-06-08 09:54:58 [+0000]:

>Whilst deploying IPsec (with strongswan-ike2) I ran into a complication[1]
>that causes mv_cesa to spin the CPU when the system receives an IPsec ESP
>packet; it seems to be able to send traffic (before the CPU spin) as a
>ICMP Echo request (a la pin) out from the system out is okay, until the
>ICMP Reply comes back. The packet never 'arrives' as far as userspace is
>concerned and the only way to stop the CPU spinning is a reboot.

I've been working on that and forgot about it in the meantime. The
problem is that incremental sha1 checksum are wrong i.e. the previous
state is ignored by the hardware.
Kernel's auto-test droppped an error message which disappeared in later
a kernel so I assumed that it was fixed. This was not case but
"oldconfig" disabled the algorithm test.

Sebastian



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110608113810.GA22401@Chamillionaire.breakpoint.c c">http://lists.debian.org/20110608113810.GA22401@Chamillionaire.breakpoint.c c
 
Old 06-09-2011, 01:44 PM
Arnaud Patard (Rtp)
 
Default Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin

Sebastian Andrzej Siewior <sebastian@breakpoint.cc> writes:

Hi,

> * Alexander Clouter | 2011-06-08 09:54:58 [+0000]:
>
>>Whilst deploying IPsec (with strongswan-ike2) I ran into a complication[1]
>>that causes mv_cesa to spin the CPU when the system receives an IPsec ESP
>>packet; it seems to be able to send traffic (before the CPU spin) as a
>>ICMP Echo request (a la pin) out from the system out is okay, until the
>>ICMP Reply comes back. The packet never 'arrives' as far as userspace is
>>concerned and the only way to stop the CPU spinning is a reboot.
>
> I've been working on that and forgot about it in the meantime. The
> problem is that incremental sha1 checksum are wrong i.e. the previous
> state is ignored by the hardware.

if it's known to be broken, what about disabling it and enable it when
it's working ?
Also, I'm not familiar with cesa support but from what I understand in
the manual, you need to change the mode bit of the 0x3dd18 regiter to
configure continuous mode and I don't see anything for that [ feel free
to correct me if I'm wrong on that ].

Also, do you have a small test case to reproduce that ?

> Kernel's auto-test droppped an error message which disappeared in later
> a kernel so I assumed that it was fixed. This was not case but
> "oldconfig" disabled the algorithm test.

You're talking of CRYPTO_MANAGER_DISABLE_TESTS, right ?

Arnaud



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87vcwfktli.fsf@lebrac.rtp-net.org">http://lists.debian.org/87vcwfktli.fsf@lebrac.rtp-net.org
 
Old 08-08-2011, 09:12 AM
Alexander Clouter
 
Default Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin

* Sebastian Andrzej Siewior <sebastian@breakpoint.cc> [2011-06-08 13:38:10+0200]:
>
> * Alexander Clouter | 2011-06-08 09:54:58 [+0000]:
>
> >Whilst deploying IPsec (with strongswan-ike2) I ran into a complication[1]
> >that causes mv_cesa to spin the CPU when the system receives an IPsec ESP
> >packet; it seems to be able to send traffic (before the CPU spin) as a
> >ICMP Echo request (a la pin) out from the system out is okay, until the
> >ICMP Reply comes back. The packet never 'arrives' as far as userspace is
> >concerned and the only way to stop the CPU spinning is a reboot.
>
> I've been working on that and forgot about it in the meantime. The
> problem is that incremental sha1 checksum are wrong i.e. the previous
> state is ignored by the hardware.
>
I have just been tasked with putting together an active-active IPsec VPN
concentrator (with a need to use AES-SHA1 it seems) and I was hoping to
use the OpenRD's (and mv_cesa). Have you got a patch I can test that
fixes things for SHA1?

Cheers

--
Alexander Clouter
.sigmonster says: You fill a much-needed gap.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110808091235.GM30944@chipmunk">http://lists.debian.org/20110808091235.GM30944@chipmunk
 
Old 08-08-2011, 08:46 PM
Sebastian Andrzej Siewior
 
Default Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin

* Thus spake Alexander Clouter (alex@digriz.org.uk):

> I have just been tasked with putting together an active-active IPsec VPN
> concentrator (with a need to use AES-SHA1 it seems) and I was hoping to
> use the OpenRD's (and mv_cesa). Have you got a patch I can test that
> fixes things for SHA1?

The patch below should work around the problem by not using it. You could try
the kernel from backports. If I remember correctly than it seems that the
later kernel passes one big chunk instead of three requests (init, update,
fin). If that works out for then the only problem are fragmanted packets.

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 3cf303e..f556a71 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -1062,7 +1062,7 @@ static int mv_probe(struct platform_device *pdev)
"Could not register aes-cbc driver
");
goto err_unreg_ecb;
}
-
+#if 0
ret = crypto_register_ahash(&mv_sha1_alg);
if (ret == 0)
cpg->has_sha1 = 1;
@@ -1076,7 +1076,7 @@ static int mv_probe(struct platform_device *pdev)
printk(KERN_WARNING MV_CESA
"Could not register hmac-sha1 driver
");
}
-
+#endif
return 0;
err_unreg_ecb:
crypto_unregister_alg(&mv_aes_alg_ecb);

> Cheers

Sebastian



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110808204638.GA10646@breakpoint.cc">http://lists.debian.org/20110808204638.GA10646@breakpoint.cc
 
Old 08-09-2011, 09:05 PM
Alexander Clouter
 
Default Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin

* Sebastian Andrzej Siewior <sebastian@breakpoint.cc> [2011-08-08 22:46:38+0200]:
>
> * Thus spake Alexander Clouter (alex@digriz.org.uk):
>
> > I have just been tasked with putting together an active-active IPsec VPN
> > concentrator (with a need to use AES-SHA1 it seems) and I was hoping to
> > use the OpenRD's (and mv_cesa). Have you got a patch I can test that
> > fixes things for SHA1?
>
> The patch below should work around the problem by not using it.
>
I'll have you know I passed with honours from the "Computing School of
Commenting Out" and as such do not require such assistance as this

> You could try the kernel from backports. If I remember correctly than
> it seems that the later kernel passes one big chunk instead of three
> requests (init, update, fin). If that works out for then the only
> problem are fragmanted packets.
>
Do not tinkering with the 'mode' bit at 0xdd18 help[1][2] (as suggested
by Arnaud)? I'm happy to be the guinea pig here.

I'll install the backports one anyway for testing and let you know.

Cheers

[1] page 458 of
http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf
[2] you might also be interested in
http://www.digriz.org.uk/ts78xx?action=AttachFile&do=get&target=88F5182_Fun ctional_Errata.pdf

--
Alexander Clouter
.sigmonster says: Knocked, you weren't in.
-- Opportunity



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110809210515.GX31044@chipmunk">http://lists.debian.org/20110809210515.GX31044@chipmunk
 

Thread Tools




All times are GMT. The time now is 10:01 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org