Re: [PATCH] crypto: aesni-intel - fix unaligned cbc decrypt for x86-32
On Thu, May 31, 2012 at 7:27 AM, Herbert Xu herb...@gondor.apana.org.au wrote: On Wed, May 30, 2012 at 01:43:08AM +0200, Mathias Krause wrote: The 32 bit variant of cbc(aes) decrypt is using instructions requiring 128 bit aligned memory locations but fails to ensure this constraint in the code. Fix this by loading the data into intermediate registers with load unaligned instructions. This fixes reported general protection faults related to aesni. References: https://bugzilla.kernel.org/show_bug.cgi?id=43223 Reported-by: Daniel gark...@mailueberfall.de Cc: sta...@kernel.org [v2.6.39+] Signed-off-by: Mathias Krause mini...@googlemail.com Have measured this against increasing alignmask to 15? No, but the latter will likely be much slower as it would need to memmove the data if it's not aligned, right? My patch essentially just breaks the combined XOR a memory operand with a register operation into two -- load memory into register, then XOR with registers. It shouldn't be much slower compared to the current version. But it fixes a bug the current version exposes when working on unaligned data. That said, I did some micro benchmark on pxor (%edx), %xmm0 vs. movups (%edx), %xmm1; pxor %xmm1, %xmm0 and observed the latter might be even slightly faster! But changing the code to perform better is out of scope for this patch as it should just fix the bug in the code. We can increase performance in a follow up patch. Mathias -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: aesni-intel - fix unaligned cbc decrypt for x86-32
On Thu, May 31, 2012 at 08:45:58AM +0200, Mathias Krause wrote: No, but the latter will likely be much slower as it would need to memmove the data if it's not aligned, right? Most crypto users should already be providing aligned data. After all, padlock-aes requires 16-byte alignment and it works quite well. That said, I did some micro benchmark on pxor (%edx), %xmm0 vs. movups (%edx), %xmm1; pxor %xmm1, %xmm0 and observed the latter might be even slightly faster! But changing the code to perform better is out of scope for this patch as it should just fix the bug in the code. We can increase performance in a follow up patch. OK we can do that. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: aesni-intel - fix unaligned cbc decrypt for x86-32
On Wed, May 30, 2012 at 01:43:08AM +0200, Mathias Krause wrote: The 32 bit variant of cbc(aes) decrypt is using instructions requiring 128 bit aligned memory locations but fails to ensure this constraint in the code. Fix this by loading the data into intermediate registers with load unaligned instructions. This fixes reported general protection faults related to aesni. References: https://bugzilla.kernel.org/show_bug.cgi?id=43223 Reported-by: Daniel gark...@mailueberfall.de Cc: sta...@kernel.org [v2.6.39+] Signed-off-by: Mathias Krause mini...@googlemail.com Patch applied to crypto. Thanks. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] crypto: talitos - Fix panic in interrupt error path
-Original Message- From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto- ow...@vger.kernel.org] On Behalf Of Helmut Schaa Sent: Wednesday, May 30, 2012 10:57 AM To: linux-crypto@vger.kernel.org Cc: Phillips Kim-R1AAHA; herb...@gondor.apana.org.au; Helmut Schaa; Sven Schnelle Subject: [PATCH] crypto: talitos - Fix panic in interrupt error path The talitos interrupt error path can generate a kernel panic when priv-chan[ch].fifo[tail].desc is NULL. Check the desc pointer before use in current_desc_hdr. Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc01e0f40 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2 P1020 RDB last sysfs file: /sys/kernel/uevent_seqnum Modules linked in: pl2303 option keyspan sg usb_wwan usbserial uhci_hcd ohci_hcd macvlan ebt_snat ebt_dnat ebt_arpreply ebt_ip ebt_arp ebt_redirect ebt_mark ebt_vlan ebt_stp ebt_pkttype ebt_mark_m ebt_limit ebt_among ebt_802_3 ebtable_nc NIP: c01e0f40 LR: c01e0ea8 CTR: c01e0ccc REGS: efff1ea0 TRAP: 0300 Not tainted (2.6.38.8) MSR: 00021000 ME,CE CR: 99355033 XER: c000 DEAR: , ESR: TASK = c03422e0[0] 'swapper' THREAD: c035a000 CPU: 0 GPR00: efff1f50 c03422e0 ef869608 ef869608 efff1ff0 GPR08: efb6ec80 efb75e00 efb75e10 1007e92c c02f1740 GPR16: c02f c02f16bc c02a ffea 0003 0001 1280 GPR24: c02d78a4 010c0100 efb380c0 002d 000186a0 ef869608 0008 NIP [c01e0f40] talitos_interrupt+0x274/0x8a0 LR [c01e0ea8] talitos_interrupt+0x1dc/0x8a0 Call Trace: [efff1fa0] [c0066aa4] handle_IRQ_event+0x44/0x110 [efff1fd0] [c0069468] handle_fasteoi_irq+0x100/0x168 [efff1ff0] [c000d0ac] call_handle_irq+0x18/0x28 [efff3c30] [c000449c] do_IRQ+0xe8/0x168 [efff3c60] [c000f0a4] ret_from_except+0x0/0x18 --- Exception: 501 at udp_queue_rcv_skb+0xe0/0x378 LR = udp_queue_rcv_skb+0xdc/0x378 [efff3d40] [c024a780] __udp4_lib_rcv+0x31c/0x5cc [efff3d80] [c0223518] ip_local_deliver_finish+0x114/0x27c [efff3da0] [c02233e0] ip_rcv_finish+0x4b0/0x4d4 [efff3dc0] [c01fa390] __netif_receive_skb+0x3f8/0x43c [efff3e10] [c01fab38] netif_receive_skb+0x98/0xac [efff3e40] [c01b84a0] gfar_clean_rx_ring+0x37c/0x470 [efff3ea0] [c01b89cc] gfar_poll+0x438/0x550 [efff3f60] [c01fae20] net_rx_action+0x88/0x170 [efff3fa0] [c0036218] __do_softirq+0xd8/0x170 [efff3ff0] [c000d084] call_do_softirq+0x14/0x24 [c035be60] [c000471c] do_softirq+0x7c/0x9c [c035be80] [c0036364] irq_exit+0x50/0x60 [c035be90] [c00044f8] do_IRQ+0x144/0x168 [c035bec0] [c000f0a4] ret_from_except+0x0/0x18 --- Exception: 501 at cpu_idle+0xc8/0x154 LR = cpu_idle+0xc8/0x154 [c035bf80] [c0008788] cpu_idle+0x150/0x154 (unreliable) [c035bfb0] [c000236c] rest_init+0x68/0x7c [c035bfc0] [c0318858] start_kernel+0x2f4/0x308 [c035bff0] [c3d8] skpinv+0x2f0/0x32c Instruction dump: 7fa3eb78 4bf98945 7c7b1b78 4838 552b2036 39290001 7d6a5a14 800b0004 7f87 409effb0 812b 7fa3eb78 8309 4bf98915 7c7b1b78 2f98 Kernel panic - not syncing: Fatal exception in interrupt Call Trace: [efff1dd0] [c0007bd0] show_stack+0x5c/0x164 (unreliable) [efff1e10] [c028206c] panic+0xa8/0x1d8 [efff1e60] [c000a654] die+0x1f8/0x23c [efff1e80] [c00135c8] bad_page_fault+0x100/0x114 [efff1e90] [c000eefc] handle_page_fault+0x7c/0x80 --- Exception: 300 at talitos_interrupt+0x274/0x8a0 LR = talitos_interrupt+0x1dc/0x8a0 [efff1f50] [] (null) (unreliable) [efff1fa0] [c0066aa4] handle_IRQ_event+0x44/0x110 [efff1fd0] [c0069468] handle_fasteoi_irq+0x100/0x168 [efff1ff0] [c000d0ac] call_handle_irq+0x18/0x28 [efff3c30] [c000449c] do_IRQ+0xe8/0x168 [efff3c60] [c000f0a4] ret_from_except+0x0/0x18 --- Exception: 501 at udp_queue_rcv_skb+0xe0/0x378 LR = udp_queue_rcv_skb+0xdc/0x378 [efff3d40] [c024a780] __udp4_lib_rcv+0x31c/0x5cc [efff3d80] [c0223518] ip_local_deliver_finish+0x114/0x27c [efff3da0] [c02233e0] ip_rcv_finish+0x4b0/0x4d4 [efff3dc0] [c01fa390] __netif_receive_skb+0x3f8/0x43c [efff3e10] [c01fab38] netif_receive_skb+0x98/0xac [efff3e40] [c01b84a0] gfar_clean_rx_ring+0x37c/0x470 [efff3ea0] [c01b89cc] gfar_poll+0x438/0x550 [efff3f60] [c01fae20] net_rx_action+0x88/0x170 [efff3fa0] [c0036218] __do_softirq+0xd8/0x170 [efff3ff0] [c000d084] call_do_softirq+0x14/0x24 [c035be60] [c000471c] do_softirq+0x7c/0x9c [c035be80] [c0036364] irq_exit+0x50/0x60 [c035be90] [c00044f8] do_IRQ+0x144/0x168 [c035bec0] [c000f0a4] ret_from_except+0x0/0x18 --- Exception: 501 at cpu_idle+0xc8/0x154 LR = cpu_idle+0xc8/0x154 [c035bf80] [c0008788] cpu_idle+0x150/0x154 (unreliable) [c035bfb0] [c000236c] rest_init+0x68/0x7c [c035bfc0] [c0318858] start_kernel+0x2f4/0x308 [c035bff0] [c3d8] skpinv+0x2f0/0x32c Signed-off-by: Helmut Schaa helmut.sc...@googlemail.com Cc: Sven Schnelle sv...@stackframe.org Cc: Kim Phillips kim.phill...@freescale.com --- Not
