http://blog.gmane.org/gmane.linux.kernel.cryptoapi hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8916 <pre>With the recent patches added to kernel crypto for improving AES support, adding aesni etc, it seems like it is time to add AES CMAC to the cifs kernel module (for the popular SMB3 signing and per-share encryption) but needed for an implementation for SP800-138 in kernel crypto codebase. Was specifically interested using the way defined in 3.1.4.2 of MS-SMB2 document, in particular KDF in Counter mode (section 5.1 of NIST SP 800-108) or a way to specify a mode PRF as HMAC-SHA256 (or a way to specify a PRF) cifs client would use this algorithm for SMB3.0 MAC generation (network packet signing on network file system mounts to newer generation NAS, and Windows 2012) and also for per-share encryption (which is also available on the most recent generation of NAS via SMB3). Apparently with current Intel processors having hardware for this kind of encryption offload - full packet encryption is faster than packet signing used to be (with the older standard algorithms) and just doing packet signing is really fast.</pre> Shirish Pargaonkar 2013-05-20T02:49:58 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8915 <pre>This patch enables the DCP crypto functionality on imx28. Currently, only aes-128-cbc is supported. Moreover, the dcpboot misc-device, which is used by Freescale's SDK tools and uses a non-software-readable OTP-key, is added. Changes of v2: - ring buffer for hardware-descriptors - use of ablkcipher walk - OTP key encryption/decryption via misc-device (compatible to Freescale-SDK) - overall cleanup The DCP is also capable of sha1/sha256 but I won't be able to add that anytime soon. Tested with built-in runtime-self-test, tcrypt and openssl via cryptodev 1.6 on imx28-evk and a custom built imx28-board. Signed-off-by: Tobias Rauter &lt;tobias.rauter&lt; at &gt;gmail.com&gt; --- arch/arm/boot/dts/imx28.dtsi | 2 +- drivers/crypto/Kconfig | 10 + drivers/crypto/Makefile | 1 + drivers/crypto/dcp.c | 925 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 937 insertions(+), 1 deletion(-) create mode 100644 drivers/crypto/dcp.c diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dt</pre> Tobias Rauter 2013-05-19T19:59:38 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8907 <pre>Hello, I have an encrypted disc (dm-crypt, type LUKS1, ssh256 as hash algorithm). I have an Intel Core i5 M450 that supports ssse3. Find below the output from netconsole with the oops. The last warning appeared when I restart the pc using the magic sysrq key combination REISUB. I have the same problem with a different laptop with an AMD E-450 APU. If you need further information, feel free to ask. Best regards, Julian Wollrath [ 3.647071] device-mapper: uevent: version 1.0.3 [ 3.647245] device-mapper: ioctl: 4.24.0-ioctl (2013-01-15) initialised: dm-devel&lt; at &gt;redhat.com [ 11.619603] sha256_ssse3: Using SSSE3 optimized SHA-256 implementation [ 12.131483] BUG: unable to handle kernel paging request at ffff8800bb593000 [ 12.131848] IP: [&lt;ffffffffa016b083&gt;] loop0+0x27/0x44 [sha256_ssse3] [ 12.132032] PGD 1a32067 PUD 1a35067 PMD 1a36067 PTE 0 [ 12.132427] Oops: 0000 [#1] SMP [ 12.132670] Modules linked in: sha256_ssse3(+) sha256_generic twofish_generic twofish_x86_64_3way xts lrw gf128mul glue</pre> Julian Wollrath 2013-05-16T13:41:35 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8818 <pre>A great deal of these patches have now been applied through various trees. We now need to grab the attention of the outstanding DMA clients (MUSB and Crypto) to progress. Also, Linus could probably do with a hand from Vinod for the remaining dmaengine patches. Thanks in advance. Documentation/devicetree/bindings/dma/ste-dma40.txt | 4 ++ Documentation/devicetree/bindings/usb/ux500-usb.txt | 50 ++++++++++++++++++ arch/arm/mach-ux500/board-mop500-audio.c | 12 ++--- arch/arm/mach-ux500/board-mop500-sdi.c | 16 +++--- arch/arm/mach-ux500/board-mop500.c | 36 +++++-------- arch/arm/mach-ux500/cpu-db8500.c | 34 ++++-------- arch/arm/mach-ux500/devices-db8500.c | 80 ---------------------------- arch/arm/mach-ux500/usb.c | 37 +++---------- drivers/crypto/ux500/cryp/cryp.h | 7 ++- drivers/crypto/ux500/cryp/cryp_core.c | 31 ++++++++++- drivers/crypto/ux5</pre> Lee Jones 2013-05-15T09:51:23 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8803 <pre>Hi, [1] patch at http://www.chronox.de/jent/jitterentropy-20130508.tar.bz2 A new version of the CPU Jitter random number generator is released at http://www.chronox.de/ . The heart of the RNG is about 30 lines of easy to read code. The readme in the main directory explains the different code files. In a previous attempt (http://lkml.org/lkml/2013/2/8/476), the first iteration received comments for the lack of tests, documentation and entropy assessment. All these concerns have been addressed. The documentation of the CPU Jitter random number generator (http://www.chronox.de/jent/doc/index.html and PDF at http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf -- the graphs and pictures are better in PDF) offers a full analysis of: - the root cause of entropy - a design of the RNG - statistical tests and analyses - entropy assessment and explanation of the flow of entropy The document also explains the core concept to have a fully decentralized entropy collector for every caller in need of entropy. The </pre> Stephan Mueller 2013-05-13T15:32:18 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8801 <pre>SEQ IN PTR command does not require pointer if RTO or PRE bit is set Updated desc_constr.h accordingly. Signed-off-by: Andrei Varvara &lt;andrei.varvara&lt; at &gt;freescale.com&gt; Reviewed-by: Phillips Kim-R1AAHA &lt;Kim.Phillips&lt; at &gt;freescale.com&gt; Reviewed-by: Fleming Andrew-AFLEMING &lt;AFLEMING&lt; at &gt;freescale.com&gt; --- drivers/crypto/caam/desc.h | 4 ++-- drivers/crypto/caam/desc_constr.h | 8 ++++++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/caam/desc.h b/drivers/crypto/caam/desc.h index f7f833b..89fa3d0 100644 --- a/drivers/crypto/caam/desc.h +++ b/drivers/crypto/caam/desc.h &lt; at &gt;&lt; at &gt; -1290,18 +1290,18 &lt; at &gt;&lt; at &gt; struct sec4_sg_entry { * SEQ_OUT_PTR Command Constructs */ /* Sequence pointer is a scatter-gather table */ #define SQOUT_SGF0x01000000 /* Appends to a previous pointer */ -#define SQOUT_PRE0x00800000 +#define SQOUT_PRESQIN_PRE /* Restore sequence with pointer/length */ -#define SQOUT_RTO0x00200000 +#define SQOUT_RTO SQIN_RTO /* Use extended length following pointer </pre> Andrei Varvara 2013-05-13T14:37:57 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8795 <pre>In case Store command is used with overwrite Shared Descriptor feature there is no need for pointer, it is using the address from which the Shared Descriptor was fetched. Signed-off-by: Andrei Varvara &lt;andrei.varvara&lt; at &gt;freescale.com&gt; Reviewed-by: Phillips Kim-R1AAHA &lt;Kim.Phillips&lt; at &gt;freescale.com&gt; Reviewed-by: Fleming Andrew-AFLEMING &lt;AFLEMING&lt; at &gt;freescale.com&gt; --- drivers/crypto/caam/desc_constr.h | 18 +++++++++++++++++- 1 files changed, 17 insertions(+), 1 deletions(-) diff --git a/drivers/crypto/caam/desc_constr.h b/drivers/crypto/caam/desc_constr.h index 19501b5..fc4470a 100644 --- a/drivers/crypto/caam/desc_constr.h +++ b/drivers/crypto/caam/desc_constr.h &lt; at &gt;&lt; at &gt; -173,18 +173,34 &lt; at &gt;&lt; at &gt; static inline void append_##cmd(u32 *desc, dma_addr_t ptr, unsigned int len, \ u32 options) \ { \ PRINT_POS; \ append_cmd_ptr(desc, ptr, len, CMD_##op | options); \ } APPEND_CMD_PTR(key, KEY) APPEND_CMD_PTR(load, LOAD) -APPEND_CMD_PTR(store, STORE) APPEND_CMD_PTR(fifo_load, FIFO_LOAD) APPEND_CMD_PTR(fifo_store, FIFO_S</pre> Andrei Varvara 2013-05-13T14:50:51 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8792 <pre>Calling runtime PM API for every block causes serious perf hit to crypto operations that are done on a long buffer. As crypto is performed on a page boundary, encrypting large buffers can cause a series of crypto operations divided by page. The runtime PM API is also called those many times. We call runtime_pm_get_sync only at beginning of the session (cra_init) and runtime_pm_put at the end. This result in upto a 50% speedup as below: Before: root&lt; at &gt;beagleboard:~# time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s After: root&lt; at &gt;beagleboard:~# time -v openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s Doing a</pre> Joel A Fernandes 2013-05-11T17:23:44 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8786 <pre>Hi! I am working on a driver for the data co processor of freescale's imx28 (should also work on mx23 and mx5). I noticed that Christoph sent a patch for this device some days ago to the crypto mailing list. As far as I see this is basically the Freescale-SDK driver with some modifications for mainline. This was also my first approach. Since this driver has some problems (duplicated code, mutex in atomic context) I decided to get the reference manual and write the driver from scratch. To prevent double work (in case Christoph or someone else does the same thing), I want to share my work here now. This is my first real kernel driver so it would be nice if someone could take some time to find the noob-mistakes and send me feedback. Things I'm working on: - get rid of the global device - at the moment the number of entries of the in/out scatterlist is limited to 20. I am working on a ringbuffer where the CPU fills the co-processors buffer while it iterates through the pages. - overall performance - ATM </pre> Tobias Rauter 2013-05-08T18:41:12 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8781 <pre> Entschuldigungen für kommen in Ihre Privatsphäre! Ich bin Rechtsanwalt Werner Erich Zeller; Ich habe einen meiner einflussreichen und wohlhabenden Kunden zum Tode; und er hatte eine sehr geheime und private Investitionen von €15,000,000.00 bei einer privaten Bank in Großbritannien hier zu Lebzeiten. Diese Investition wurde ohne einen deklarierten nächsten Angehörigen und begünstigte. Jetzt brauche ich Sie arbeiten mit mir als mein Partner zu erholen und zu je 50 % Aktienfonds. Alle Dokumente werden rechtlich beantragt und beschafft, und in 5 Werktage, wird diese Transaktion auftreten. Aber ich brauche einen ernsten, treuen und glaubwürdigen Partner. Bitte senden Sie mir eine vertrauliche Antwort, wenn Sie denken, Sie vertraut werden können und sind von den Qualitäten! Ich warte auf Ihre schnelle Antwort. Werner Erich Zeller (Rechtsanwalt) Rufen Sie + 44-702-409-0820 (Office) </pre> John P. Goldman 2013-05-08T08:46:28 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8774 <pre>The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han &lt;jg1.han&lt; at &gt;samsung.com&gt; --- drivers/crypto/s5p-sss.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c index 4b31432..cf149b1 100644 --- a/drivers/crypto/s5p-sss.c +++ b/drivers/crypto/s5p-sss.c &lt; at &gt;&lt; at &gt; -647,7 +647,6 &lt; at &gt;&lt; at &gt; static int s5p_aes_probe(struct platform_device *pdev) clk_disable(pdata-&gt;clk); s5p_dev = NULL; -platform_set_drvdata(pdev, NULL); return err; } &lt; at &gt;&lt; at &gt; -668,7 +667,6 &lt; at &gt;&lt; at &gt; static int s5p_aes_remove(struct platform_device *pdev) clk_disable(pdata-&gt;clk); s5p_dev = NULL; -platform_set_drvdata(pdev, NULL); return 0; } </pre> Jingoo Han 2013-05-06T03:49:28 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8773 <pre>The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han &lt;jg1.han&lt; at &gt;samsung.com&gt; --- drivers/crypto/mv_cesa.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c index ce6290e..3374a3e 100644 --- a/drivers/crypto/mv_cesa.c +++ b/drivers/crypto/mv_cesa.c &lt; at &gt;&lt; at &gt; -1146,7 +1146,6 &lt; at &gt;&lt; at &gt; err_unmap_reg: err: kfree(cp); cpg = NULL; -platform_set_drvdata(pdev, NULL); return ret; } </pre> Jingoo Han 2013-05-06T03:48:41 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8772 <pre></pre> Webmaster Help Desk 2013-05-03T16:12:46 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8765 <pre>Commit 0998d06310 (device-core: Ensure drvdata = NULL when no driver is bound) removes the need to set driver data field to NULL. Signed-off-by: Sachin Kamat &lt;sachin.kamat&lt; at &gt;linaro.org&gt; Cc: Sebastian Andrzej Siewior &lt;sebastian&lt; at &gt;breakpoint.cc&gt; --- drivers/crypto/mv_cesa.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c index ce6290e..3374a3e 100644 --- a/drivers/crypto/mv_cesa.c +++ b/drivers/crypto/mv_cesa.c &lt; at &gt;&lt; at &gt; -1146,7 +1146,6 &lt; at &gt;&lt; at &gt; err_unmap_reg: err: kfree(cp); cpg = NULL; -platform_set_drvdata(pdev, NULL); return ret; } </pre> Sachin Kamat 2013-05-03T09:18:14 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8763 <pre>Replace calls to deprecated devm_request_and_ioremap by devm_ioremap_resource. Found with coccicheck and this semantic patch: scripts/coccinelle/api/devm_request_and_ioremap.cocci. Signed-off-by: Laurent Navet &lt;laurent.navet&lt; at &gt;gmail.com&gt; --- drivers/crypto/omap-aes.c | 7 +++---- drivers/crypto/omap-sham.c | 7 +++---- 2 files changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c index 6aa425f..158215c 100644 --- a/drivers/crypto/omap-aes.c +++ b/drivers/crypto/omap-aes.c &lt; at &gt;&lt; at &gt; -1125,10 +1125,9 &lt; at &gt;&lt; at &gt; static int omap_aes_probe(struct platform_device *pdev) if (err) goto err_res; -dd-&gt;io_base = devm_request_and_ioremap(dev, &amp;res); -if (!dd-&gt;io_base) { -dev_err(dev, "can't ioremap\n"); -err = -ENOMEM; +dd-&gt;io_base = devm_ioremap_resource(dev, &amp;res); +if (IS_ERR(dd-&gt;io_base)) { +err = PTR_ERR(dd-&gt;io_base); goto err_res; } dd-&gt;phys_base = res.start; diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c index 3d1611f..</pre> Laurent Navet 2013-05-02T12:00:38 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8752 <pre>Currently the CRC-T10DIF checksum is computed using a generic table lookup algorithm. By switching the checksum to PCLMULQDQ based computation, we can speedup the computation by 8x for checksumming 512 bytes and even more for larger buffer size. This will improve performance of SCSI drivers turning on the CRC-T10IDF checksum. In our SSD based experiments, we have seen increase disk throughput by 3.5x with T10DIF for 512 byte block size. This patch set provides the x86_64 routine using PCLMULQDQ instruction and switches the crc_t10dif library function to use the faster PCLMULQDQ based routine when available. Tim v3 1. Update the crct10dif crypto transform used in the crct10dif library in a safe way. 2. Load the accelerated t10dif transform for the x86_64 cpus that support it. 3. Added generic crct10dif crypto transform. v2 1. Get rid of unnecessary xmm registers save and restore and fix ENDPROC position in PCLMULQDQ version of crc t10dif computation. 2. Fix URL to paper reference of CRC computation wit</pre> Tim Chen 2013-05-01T19:52:47 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8747 <pre>From: "Christoph G. Baumann" &lt;cb&lt; at &gt;sgoc.de&gt; Following Shawn Guo's (maintainer of the Freescale MXS platform) I post this patch on linux-crypto: This patch is based on the original driver by Freescale. The driver gives access to the DCP crypto core which can accelerate AES and SHA operations. It was ported to the current API and sanitized to please checkpatch.pl. Christoph G. Baumann (2): crypto: added support for fsl-dcp on iMX23,28,50 crypto: added support for fsl-dcp on iMX23,28,50 arch/arm/boot/dts/imx28.dtsi | 2 +- drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + drivers/staging/crypto/Kconfig | 15 + drivers/staging/crypto/Makefile | 1 + drivers/staging/crypto/fsl-dcp.c | 1790 ++++++++++++++++++++++++++ drivers/staging/crypto/fsl-dcp.h | 739 +++++++++++ include/linux/fsl/fsl-dcp_bootstream_ioctl.h | 32 + 8 files changed, 2581 insertions(+), 1 deletion(-) </pre> Christoph G. Baumann 2013-04-29T19:58:34 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8738 <pre>For SEC including a RNG block version &gt;= 4, special initialization must occur before any descriptor that uses RNG block can be submitted. This initialization is required not only for SEC with version greater than 5.0, but for SEC with RNG version &gt;=4. There may be a case where RNG has already been instantiated by u-boot or boot ROM code.In such SoCs, if RNG is initialized again SEC would returns "Instantiation error". Hence, the initialization status of RNG4 should be also checked before doing RNG init. Signed-off-by: Ruchika Gupta &lt;ruchika.gupta&lt; at &gt;freescale.com&gt; Signed-off-by: Alex Porosanu &lt;alexandru.porosanu&lt; at &gt;freescale.com&gt; Signed-off-by: Andy Fleming &lt;afleming&lt; at &gt;freescale.com&gt; --- This patch supersedes the patchset submitted earlier http://www.mail-archive.com/linux-crypto&lt; at &gt;vger.kernel.org/msg08348.html crypto: caam - support for RNG version retrieval crypto: caam - fix RNG init for SEC with RNG version greater than 4 drivers/crypto/caam/ctrl.c | 10 +++++++--- drivers/crypto/caam/regs.h | 42 ++++++++++</pre> Ruchika Gupta 2013-04-26T10:14:54 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8716 <pre>The current code increases its stack frame size a couple of times throughout the function, but still performs some writes below the stack pointer. This change applies the fix from the original author so all writes to the stack are above the stack pointer. Taken from origin: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=1a9d60d2 Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel&lt; at &gt;linaro.org&gt; --- arch/arm/crypto/sha1-armv4-large.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/crypto/sha1-armv4-large.S b/arch/arm/crypto/sha1-armv4-large.S index 92c6eed..99207c4 100644 --- a/arch/arm/crypto/sha1-armv4-large.S +++ b/arch/arm/crypto/sha1-armv4-large.S &lt; at &gt;&lt; at &gt; -195,6 +195,7 &lt; at &gt;&lt; at &gt; ENTRY(sha1_block_data_order) addr3,r3,r10&lt; at &gt; E+=F_00_19(B,C,D) cmpr14,sp bne.L_00_15&lt; at &gt; [((11+4)*5+2)*3] +subsp,sp,#25*4 #if __ARM_ARCH__&lt;7 ldrbr10,[r1,#2] ldrbr9,[r1,#3] &lt; at &gt;&lt; at &gt; -290,7 +291,6 &lt; at &gt;&lt; at &gt; ENTRY(sha1_block_data_order) addr3,r3,r10&lt; at &gt; E+=F_00_19(B,C,D) ldrr8,.LK_20_39&lt; at &gt; [+15+1</pre> Ard Biesheuvel 2013-04-25T12:51:50 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8676 <pre>The job ring init function creates a platform device for each job ring. While the job ring is shutdown, e.g. while caam module removal, its platform device was not being removed. This leads to failure while reinsertion and then removal of caam module second time. The following kernel crash dump appears when caam module is reinserted and then removed again. This patch fixes it. root&lt; at &gt;p4080ds:~# rmmod caam.ko Unable to handle kernel paging request for data at address 0x00000008 Faulting instruction address: 0xf94aca18 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=8 P4080 DS Modules linked in: caam(-) qoriq_dbg(O) [last unloaded: caam] NIP: f94aca18 LR: f94aca18 CTR: c029f950 REGS: eac47d60 TRAP: 0300 Tainted: G O (3.8.4-rt2) MSR: 00029002 &lt;CE,EE,ME&gt; CR: 22022484 XER: 20000000 DEAR: 00000008, ESR: 00000000 TASK = e49dfaf0[2110] 'rmmod' THREAD: eac46000 CPU: 1 GPR00: f94ad3f4 eac47e10 e49dfaf0 00000000 00000005 ea2ac210 ffffffff 00000000 GPR08: c286de68 e4977ce0 c029b1c0 00000001 c0</pre> Vakul Garg 2013-04-15T04:25:51 http://comments.gmane.org/gmane.linux.kernel.cryptoapi/8674 <pre>When user requests encryption (or decryption) of block which is not aligned to cipher block size through userspace crypto interface, an OOps like this can happen: [ 112.738285] BUG: unable to handle kernel paging request at e1c44840 [ 112.738407] IP: [&lt;c121f473&gt;] scatterwalk_done+0x53/0x70 ... [ 112.740515] Call Trace: [ 112.740588] [&lt;c1221d30&gt;] blkcipher_walk_done+0x160/0x1e0 [ 112.740663] [&lt;c12220c8&gt;] blkcipher_walk_next+0x318/0x3c0 [ 112.740737] [&lt;c12221e0&gt;] blkcipher_walk_first+0x70/0x160 [ 112.740811] [&lt;c1222327&gt;] blkcipher_walk_virt+0x17/0x20 [ 112.740886] [&lt;e0ce4249&gt;] cbc_encrypt+0x29/0x100 [aesni_intel] [ 112.740968] [&lt;c1029f73&gt;] ? get_user_pages_fast+0x123/0x150 [ 112.741046] [&lt;c106e7db&gt;] ? trace_hardirqs_on+0xb/0x10 [ 112.741119] [&lt;e081e1c9&gt;] __ablk_encrypt+0x39/0x40 [ablk_helper] [ 112.741198] [&lt;e081e1ea&gt;] ablk_encrypt+0x1a/0x70 [ablk_helper] [ 112.741275] [&lt;e0f715ac&gt;] skcipher_recvmsg+0x20c/0x400 [algif_skcipher] [ 112.741359] [&lt;c1056a1d&gt;] ? sched_clock_cpu+0x11d/0x1a0 [</pre> Milan Broz 2013-04-14T16:12:32 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.kernel.cryptoapi