Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin
* Sebastian Andrzej Siewior sebast...@breakpoint.cc [2011-08-08 22:46:38+0200]: * Thus spake Alexander Clouter (a...@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=AttachFiledo=gettarget=88F5182_Functional_Errata.pdf -- Alexander Clouter .sigmonster says: Knocked, you weren't in. -- Opportunity -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin
* Sebastian Andrzej Siewior sebast...@breakpoint.cc [2011-06-08 13:38:10+0200]: * Alexander Clouter | 2011-06-08 09:54:58 [+]: 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin
* Thus spake Alexander Clouter (a...@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\n); 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\n); } - +#endif return 0; err_unreg_ecb: crypto_unregister_alg(mv_aes_alg_ecb); Cheers Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin
Sebastian Andrzej Siewior sebast...@breakpoint.cc writes: Hi, * Alexander Clouter | 2011-06-08 09:54:58 [+]: 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-vgerm=130746635214483w=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) (da...@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: ** Loaded modules: Module Size Used by xfrm6_mode_tunnel 1474 0 xfrm4_mode_tunnel 1546 0 esp64591 0 xfrm6_mode_transport 1300 0 authenc 5940 0 xfrm4_mode_transport 1276 0 xt_multiport2341 1 xfrm_user 18561 2 xfrm4_tunnel1407 0 tunnel4 2035 1 xfrm4_tunnel ipcomp 1698 0 xfrm_ipcomp 3557 1 ipcomp esp44807 0 ah4 3703 0 ctr 3241 0 twofish 7467 0 twofish_common 14498 1 twofish camellia 21397 0 serpent21417 0 blowfish8262 0 cast5 16967 0 des_generic16617 0 cbc 2313 0 xcbc2219 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_iser25394 0 rdma_cm22074 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_core40421 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_iscsi25876 4 ib_iser,iscsi_tcp,libiscsi fuse 51372 3 ip6_tunnel 11756 0 tunnel6 1866 1 ip6_tunnel bonding78390 0 ipv6 253910 52
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 [+]: 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
