Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Sat, Apr 08, 2017 at 10:02:46AM +0800, Herbert Xu wrote: > On Thu, Apr 06, 2017 at 05:54:14PM +0800, Herbert Xu wrote: > > On Mon, Mar 13, 2017 at 07:06:01PM +0200, Krzysztof Kozlowski wrote: > > > > > > I bisected this to commit f1c131b45410 ("crypto: xts - Convert to > > > skcipher"). The s5p-sss driver stays the same... but the xts changes and > > > as a result we have a NULL pointer dereference (actually of value > > > 0004): > > > [ 18.930195] Unable to handle kernel NULL pointer dereference at > > > virtual address 0004 > > > ... > > > [ 18.972325] [] (post_crypt) from [] > > > (decrypt_done+0x4c/0x54) > > > [ 18.972343] [] (decrypt_done) from [] > > > (s5p_aes_interrupt+0x1bc/0x208) > > > [ 18.972360] [] (s5p_aes_interrupt) from [] > > > (irq_thread_fn+0x1c/0x54) > > > > > > Any hints? > > > > I haven't found any smoking guns, but the locking between the > > tasklet and the IRQ routine looks suspect. First of all the > > tasklet is modifying the dev structure without holding any locks. > > I think I see the problem. Could you please try this patch and > let me know if it fixes the crash? Yes, fixed! Thanks. Tested on Odroid XU3 with following script: https://github.com/krzk/tools/blob/master/tests/s5p-sss-cryptsetup.sh Tested-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Thu, Apr 06, 2017 at 05:54:14PM +0800, Herbert Xu wrote: > On Mon, Mar 13, 2017 at 07:06:01PM +0200, Krzysztof Kozlowski wrote: > > > > I bisected this to commit f1c131b45410 ("crypto: xts - Convert to > > skcipher"). The s5p-sss driver stays the same... but the xts changes and > > as a result we have a NULL pointer dereference (actually of value > > 0004): > > [ 18.930195] Unable to handle kernel NULL pointer dereference at virtual > > address 0004 > > ... > > [ 18.972325] [] (post_crypt) from [] > > (decrypt_done+0x4c/0x54) > > [ 18.972343] [] (decrypt_done) from [] > > (s5p_aes_interrupt+0x1bc/0x208) > > [ 18.972360] [] (s5p_aes_interrupt) from [] > > (irq_thread_fn+0x1c/0x54) > > > > Any hints? > > I haven't found any smoking guns, but the locking between the > tasklet and the IRQ routine looks suspect. First of all the > tasklet is modifying the dev structure without holding any locks. I think I see the problem. Could you please try this patch and let me know if it fixes the crash? ---8<--- Subject: crypto: xts - Fix use-after-free on EINPROGRESS When we get an EINPROGRESS completion in xts, we will end up marking the request as done and freeing it. This then blows up when the request is really completed as we've already freed the memory. Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher") Cc: Reported-by: Nathan Royce Reported-by: Krzysztof Kozlowski Signed-off-by: Herbert Xu diff --git a/crypto/xts.c b/crypto/xts.c index e197e64..d86c11a 100644 --- a/crypto/xts.c +++ b/crypto/xts.c @@ -286,6 +286,13 @@ static void encrypt_done(struct crypto_async_request *areq, int err) struct rctx *rctx; rctx = skcipher_request_ctx(req); + + if (err == -EINPROGRESS) { + if (rctx->left != req->cryptlen) + return; + goto out; + } + subreq = &rctx->subreq; subreq->base.flags &= CRYPTO_TFM_REQ_MAY_BACKLOG; @@ -293,6 +300,7 @@ static void encrypt_done(struct crypto_async_request *areq, int err) if (rctx->left) return; +out: skcipher_request_complete(req, err); } @@ -330,6 +338,13 @@ static void decrypt_done(struct crypto_async_request *areq, int err) struct rctx *rctx; rctx = skcipher_request_ctx(req); + + if (err == -EINPROGRESS) { + if (rctx->left != req->cryptlen) + return; + goto out; + } + subreq = &rctx->subreq; subreq->base.flags &= CRYPTO_TFM_REQ_MAY_BACKLOG; @@ -337,6 +352,7 @@ static void decrypt_done(struct crypto_async_request *areq, int err) if (rctx->left) return; +out: skcipher_request_complete(req, err); } -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Mon, Mar 13, 2017 at 07:06:01PM +0200, Krzysztof Kozlowski wrote: > > I bisected this to commit f1c131b45410 ("crypto: xts - Convert to > skcipher"). The s5p-sss driver stays the same... but the xts changes and > as a result we have a NULL pointer dereference (actually of value > 0004): > [ 18.930195] Unable to handle kernel NULL pointer dereference at virtual > address 0004 > ... > [ 18.972325] [] (post_crypt) from [] > (decrypt_done+0x4c/0x54) > [ 18.972343] [] (decrypt_done) from [] > (s5p_aes_interrupt+0x1bc/0x208) > [ 18.972360] [] (s5p_aes_interrupt) from [] > (irq_thread_fn+0x1c/0x54) > > Any hints? I haven't found any smoking guns, but the locking between the tasklet and the IRQ routine looks suspect. First of all the tasklet is modifying the dev structure without holding any locks. More importantly, the IRQ routine does not seem to be robust in the face of spurious interrupts. Should a spurious interrupt arrive, it is entirely possible for the tasklet's modifying of dev->req to race with the IRQ routine which reads dev->req. However, this does depend on there being a spurious interrupt so I don't know how likely it is. Anyway, if we can't get to the bottom of this, we should disable the broken functionality. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Mon, Mar 13, 2017 at 07:06:01PM +0200, Krzysztof Kozlowski wrote: > > I bisected this to commit f1c131b45410 ("crypto: xts - Convert to > skcipher"). The s5p-sss driver stays the same... but the xts changes and > as a result we have a NULL pointer dereference (actually of value > 0004): > [ 18.930195] Unable to handle kernel NULL pointer dereference at virtual > address 0004 > ... > [ 18.972325] [] (post_crypt) from [] > (decrypt_done+0x4c/0x54) > [ 18.972343] [] (decrypt_done) from [] > (s5p_aes_interrupt+0x1bc/0x208) > [ 18.972360] [] (s5p_aes_interrupt) from [] > (irq_thread_fn+0x1c/0x54) Well that's hardly surprising since xts prior to this commit used simple AES as opposed to ecb(aes) so it couldn't have triggered this bug. > Any hints? I'll have a look when I have time but no promises. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Sun, Mar 12, 2017 at 09:13:22PM +0200, Krzysztof Kozlowski wrote: > On Fri, Mar 10, 2017 at 03:44:45PM -0600, Nathan Royce wrote: > > Sure, I went ahead and rebuilt it just using the bare exynos_defconfig > > and adding XTS and ECB and no other changes. > > > > No flags were used. No patches were used other than the 2 you > > provided. Just the barest of bears, the barest of bones, the barest of > > deserts, the barest of hairless cats. > > > > Okay, I reproduced it. Beside enabling crypto tests, ECB and XTS, the > important step is to disable the "ARM Accelerated Cryptographic > Algorithms" so S5P-SSS will be used with XTS. The xts(ecb-aes-s5p)) > itself passes TCRYPT tests but oopses on cryptswap. Hi Herbert, I bisected this to commit f1c131b45410 ("crypto: xts - Convert to skcipher"). The s5p-sss driver stays the same... but the xts changes and as a result we have a NULL pointer dereference (actually of value 0004): [ 18.930195] Unable to handle kernel NULL pointer dereference at virtual address 0004 ... [ 18.972325] [] (post_crypt) from [] (decrypt_done+0x4c/0x54) [ 18.972343] [] (decrypt_done) from [] (s5p_aes_interrupt+0x1bc/0x208) [ 18.972360] [] (s5p_aes_interrupt) from [] (irq_thread_fn+0x1c/0x54) Any hints? Best regards, Krzysztof
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Fri, Mar 10, 2017 at 03:44:45PM -0600, Nathan Royce wrote: > Sure, I went ahead and rebuilt it just using the bare exynos_defconfig > and adding XTS and ECB and no other changes. > > No flags were used. No patches were used other than the 2 you > provided. Just the barest of bears, the barest of bones, the barest of > deserts, the barest of hairless cats. > Okay, I reproduced it. Beside enabling crypto tests, ECB and XTS, the important step is to disable the "ARM Accelerated Cryptographic Algorithms" so S5P-SSS will be used with XTS. The xts(ecb-aes-s5p)) itself passes TCRYPT tests but oopses on cryptswap. Best regards, Krzysztof
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
Sure, I went ahead and rebuilt it just using the bare exynos_defconfig and adding XTS and ECB and no other changes. No flags were used. No patches were used other than the 2 you provided. Just the barest of bears, the barest of bones, the barest of deserts, the barest of hairless cats. I also wiped out the 4.10.1 modules directory and zImage and dtb before copying them into place. * [ 16.280951] s5p-jpeg 11f6.jpeg: Samsung S5P JPEG codec [ 16.327434] CPU: 3 PID: 115 Comm: irq/69-1083 Not tainted 4.10.1-dirty #1 [ 16.334527] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 16.340533] task: edc52d00 task.stack: edcc [ 16.345040] PC is at post_crypt+0x194/0x1a0 [xts] [ 16.349712] LR is at post_crypt+0x188/0x1a0 [xts] [ 16.354390] pc : []lr : []psr: 200d0113 [ 16.354390] sp : edcc1ea8 ip : ed6f38f4 fp : 30702272 [ 16.365838] r10: 8ee5436d r9 : r8 : ed6f3800 [ 16.371023] r7 : r6 : 0400 r5 : r4 : [ 16.377523] r3 : ef5ead22 r2 : 0200 r1 : 0200 r0 : [ 16.384024] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 16.391128] Control: 10c5387d Table: 6d6f806a DAC: 0051 [ 16.396847] Process irq/69-1083 (pid: 115, stack limit = 0xedcc0210) [ 16.403519] Stack: (0xedcc1ea8 to 0xedcc2000) [ 16.407853] 1ea0: c0c08304 ef5ead20 ecd69200 ef5ead20 ecd69200 ed6f39dc [ 16.416011] 1ec0: 0400 0400 c010f774 c0113bac [ 16.424156] 1ee0: 0010 0010 000f [ 16.432302] 1f00: ed6f3800 edcae3bc 000c edcae3e8 600d0113 ee889d5c bf182764 [ 16.440447] 1f20: edcae390 c0566d84 0001 edcacec0 eea14b00 eea14b00 [ 16.448592] 1f40: edcacec0 c01651c4 eeb00528 c01651e0 edcc edcacee4 c01654b4 [ 16.456738] 1f60: c01652b8 eeb00500 edcc edcacf00 edcacec0 c0165388 [ 16.464884] 1f80: eeb00528 c013673c edcc edcacf00 c0136634 [ 16.473029] 1fa0: c0107778 [ 16.481174] 1fc0: [ 16.489320] 1fe0: 0013 [ 16.497473] [] (post_crypt [xts]) from [] (decrypt_done+0x4c/0x54 [xts]) [ 16.505877] [] (decrypt_done [xts]) from [] (s5p_aes_interrupt+0x1bc/0x208) [ 16.514544] [] (s5p_aes_interrupt) from [] (irq_thread_fn+0x1c/0x54) [ 16.522592] [] (irq_thread_fn) from [] (irq_thread+0x12c/0x1e0) [ 16.530220] [] (irq_thread) from [] (kthread+0x108/0x138) [ 16.537324] [] (kthread) from [] (ret_from_fork+0x14/0x3c) [ 16.544514] Code: eb471ad2 e598c118 e58d0020 e1a04000 (e5906004) [ 16.550709] ---[ end trace 0e5ce4ea2ad2d7e2 ]--- [ 16.555224] genirq: exiting task "irq/69-1083" (115) is an active IRQ thread (irq 69) * I'm sure you could just copy my crypttab and fstab entries that is shown in my first email. On Fri, Mar 10, 2017 at 12:06 PM, Krzysztof Kozlowski wrote: > On Thu, Mar 09, 2017 at 05:16:35AM -0600, Nathan Royce wrote: >> Gave it a try on 4.10.1, but still to no avail: > > (...) > >> Also for the sake of testing, I did not add any FLAGS for compilation this >> time. > > Damn, I am fixing bugs around but not the one you are hitting. Can you > also check if exynos_defconfig (+XTS + any other needed setting sfor > you) also has this issue? > > I want to reproduce it but my setup does not use cryptswap. Probably I > will have to set it up. > > Best regards, > Krzysztof > config_s5psss.tar.gz Description: GNU Zip compressed data
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Thu, Mar 09, 2017 at 05:16:35AM -0600, Nathan Royce wrote: > Gave it a try on 4.10.1, but still to no avail: (...) > Also for the sake of testing, I did not add any FLAGS for compilation this > time. Damn, I am fixing bugs around but not the one you are hitting. Can you also check if exynos_defconfig (+XTS + any other needed setting sfor you) also has this issue? I want to reproduce it but my setup does not use cryptswap. Probably I will have to set it up. Best regards, Krzysztof
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
Gave it a try on 4.10.1, but still to no avail: * [8.516138] raid6: using intx1 recovery algorithm [ [0;32m OK [0m] Started Flush Journal to Persistent Storage. [9.692091] Unable to handle kernel NULL pointer dereference at virtual address 0004 [9.698896] pgd = c0004000 [9.701489] [0004] *pgd= [9.705055] Internal error: Oops: 17 [#1] SMP ARM [9.709677] Modules linked in: xor_neon zlib_deflate aes_arm raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc ip_tables x_tables [9.719177] xor: measuring software checksum speed [9.727455] CPU: 2 PID: 121 Comm: irq/69-1083 Not tainted 4.10.1-dirty #1 [9.728911]arm4regs : 304.000 MB/sec [9.738707] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [9.738913]8regs : 224.000 MB/sec [9.748924]32regs: 208.000 MB/sec [9.753095] task: edc80b00 task.stack: edd08000 [9.757626] PC is at post_crypt+0x1b4/0x1c4 [9.758914]neon : 316.000 MB/sec [9.758927] xor: using function: neon (316.000 MB/sec) [9.771040] LR is at post_crypt+0x1a8/0x1c4 [9.775197] pc : []lr : []psr: 200c0013 [9.775197] sp : edd09e90 ip : edcd64f4 fp : 02cfca75 [9.786670] r10: 3df4074e r9 : c0c0540c r8 : edcd6400 [9.791831] r7 : r6 : 0400 r5 : r4 : [9.798333] r3 : ef4a775a r2 : 0200 r1 : 0200 r0 : [9.804834] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [9.811901] Control: 10c5387d Table: 6c61c06a DAC: 0051 [9.817618] Process irq/69-1083 (pid: 121, stack limit = 0xedd08218) [9.824291] Stack: (0xedd09e90 to 0xedd0a000) [9.828624] 9e80: ef4a7758 ecca6200 ef4a7758 ecca6200 [9.836781] 9ea0: edcd65dc 0400 0400 eea8f810 0002 [9.844926] 9ec0: 0010 0010 [9.853072] 9ee0: 000f 00040a01 ee958390 edcd6400 ee9583bc 000c ee9583e8 [9.861217] 9f00: 600c0013 ee889d20 c033608c ee958390 c05a7ea8 0001 [9.869363] 9f20: ee957b40 eea8a400 eea8a400 ee957b40 c016ee68 c0c0540c c016ee84 [9.877508] 9f40: edd08000 ee957b64 eea8a400 c016f198 ee957b80 c016ef7c 00040a01 [9.885653] 9f60: eea21380 edd08000 ee957b80 ee957b40 c016f04c eea213a8 [9.893800] 9f80: ee889d20 c0138710 edd08000 ee957b80 c0138608 [9.901944] 9fa0: c0107a38 [9.910089] 9fc0: [9.918235] 9fe0: 0013 [9.926399] [] (post_crypt) from [] (decrypt_done+0x4c/0x54) [9.933761] [] (decrypt_done) from [] (s5p_aes_interrupt+0x1bc/0x208) [9.941908] [] (s5p_aes_interrupt) from [] (irq_thread_fn+0x1c/0x54) [9.949956] [] (irq_thread_fn) from [] (irq_thread+0x14c/0x204) [9.957585] [] (irq_thread) from [] (kthread+0x108/0x138) [9.964681] [] (kthread) from [] (ret_from_fork+0x14/0x3c) [9.971871] Code: eb0114aa e598c118 e58d001c e1a04000 (e5906004) [9.977963] ---[ end trace 8c160bf6676cfe1c ]--- [9.982560] genirq: exiting task "irq/69-1083" (121) is an active IRQ thread (irq 69) [ 11.715339] Btrfs loaded, crc32c=crc32c-generic * Also for the sake of testing, I did not add any FLAGS for compilation this time. On Wed, Mar 8, 2017 at 3:15 PM, Krzysztof Kozlowski wrote: > On Wed, Mar 08, 2017 at 07:45:42PM +0200, Krzysztof Kozlowski wrote: > I sent a fix. At least for spin lock recursion in tcrypt. > > Could you give it a try? > > Best regards, > Krzysztof
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Wed, Mar 08, 2017 at 07:45:42PM +0200, Krzysztof Kozlowski wrote: > On Mon, Mar 06, 2017 at 03:29:48PM -0600, Nathan Royce wrote: > > OK, I just tried 4.10.0 and the output is looking the same. > > > > I can't say my setup is all that odd. The cryptographic use is only > > with the swap partition found in my original email (seen in Herbert's > > reply). > > You have quite specific/customized config and compilation flags. > I doubt that it causes the issue but at least the config is unusable on > anything other then XU3/XU4. > > Anyway I reproduced some of the issues with tcrypt on Odroid U3 on v4.10 > and v4.11-rc1, with regular exynos defconfig plus some more crypto > algorithms: > 1. Without my patch: the original warning. > 2. With my patch: I sent a fix. At least for spin lock recursion in tcrypt. Could you give it a try? Best regards, Krzysztof
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Mon, Mar 06, 2017 at 03:29:48PM -0600, Nathan Royce wrote: > OK, I just tried 4.10.0 and the output is looking the same. > > I can't say my setup is all that odd. The cryptographic use is only > with the swap partition found in my original email (seen in Herbert's > reply). You have quite specific/customized config and compilation flags. I doubt that it causes the issue but at least the config is unusable on anything other then XU3/XU4. Anyway I reproduced some of the issues with tcrypt on Odroid U3 on v4.10 and v4.11-rc1, with regular exynos defconfig plus some more crypto algorithms: 1. Without my patch: the original warning. 2. With my patch: [ 95.170527] testing speed of async lrw(aes) (lrw(ecb-aes-s5p)) encryption [ 95.173990] tcrypt: test 0 (256 bit key, 16 byte blocks): 19007 operations in 1 seconds (304112 bytes) [ 96.175986] tcrypt: test 1 (256 bit key, 64 byte blocks): 15753 operations in 1 seconds (1008192 bytes) [ 97.176099] tcrypt: test 2 (256 bit key, 256 byte blocks): 14293 operations in 1 seconds (3659008 bytes) [ 98.176177] tcrypt: test 3 (256 bit key, 1024 byte blocks): 11906 operations in 1 seconds (12191744 bytes) [ 99.176407] tcrypt: test 4 (256 bit key, 8192 byte blocks): [ 99.177235] BUG: spinlock recursion on CPU#1, irq/84-1083/89 [ 99.188034] lock: 0xeea99a68, .magic: dead4ead, .owner: irq/84-1083/89, .owner_cpu: 1 [ 99.196282] CPU: 1 PID: 89 Comm: irq/84-1083 Not tainted 4.11.0-rc1-1-g897ca6d0800d #559 [ 99.205038] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 99.211158] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 99.218863] [] (show_stack) from [] (dump_stack+0x78/0x8c) [ 99.226060] [] (dump_stack) from [] (do_raw_spin_lock+0x11c/0x120) [ 99.233962] [] (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x20/0x28) [ 99.242733] [] (_raw_spin_lock_irqsave) from [] (s5p_aes_crypt+0x2c/0xb4) [ 99.251240] [] (s5p_aes_crypt) from [] (do_encrypt+0x78/0xb0 [lrw]) [ 99.259230] [] (do_encrypt [lrw]) from [] (encrypt_done+0x24/0x54 [lrw]) [ 99.267628] [] (encrypt_done [lrw]) from [] (s5p_aes_complete+0x60/0xcc) [ 99.276046] [] (s5p_aes_complete) from [] (s5p_aes_interrupt+0x134/0x1a0) [ 99.284558] [] (s5p_aes_interrupt) from [] (irq_thread_fn+0x1c/0x54) [ 99.292624] [] (irq_thread_fn) from [] (irq_thread+0x12c/0x1e0) [ 99.300269] [] (irq_thread) from [] (kthread+0x108/0x138) [ 99.307382] [] (kthread) from [] (ret_from_fork+0x14/0x3c) I will take a look into this. Thanks for the report. Best regards, Krzysztof
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
OK, I just tried 4.10.0 and the output is looking the same. I can't say my setup is all that odd. The cryptographic use is only with the swap partition found in my original email (seen in Herbert's reply). My normal build goes as such: 1) git clean -xdf 2) git reset --hard 3) curl https://github.com/tobetter/linux/commit/9cdf86bac1db2d74bf98508226e86679581f8f80.patch | git apply - //usb: host: xhci-plat: Get PHYs for xhci's hcds 4) curl https://github.com/tobetter/linux/commit/142cf1b68fa0e1710f3623875d5c269cbbc2f005.patch | git apply - //base: platform: name the device already during allocation 5) curl https://github.com/tobetter/linux/commit/3772f11d73289ea40825f40ba5c64b5b0e3888ff.patch | git apply - //phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800 6) sed -i -e "s/static void exynos5420_usbdrd_phy_calibrate/static int exynos5420_usbdrd_phy_calibrate/" ./drivers/phy/phy-exynos5-usbdrd.c 7) //duplicate entry in drivers/media/usb/au0828/au0828-cards.c for my 0x400 vid tuner. 8) HOST_EXTRACFLAGS="-O3 -pipe -mfpu=neon-vfpv4 -mfloat-abi=hard -march=armv7-a -mtune=cortex-a15.cortex-a7" make -j 8 zImage exynos5422-odroidxu4.dtb modules 2>&1 | tee make.log 9) INSTALL_MOD_PATH=./tmp INSTALL_FW_PATH=./tmp make modules_install firmware_install 2>&1 | tee makeModFirm.log 10) sudo cp -rv ./tmp/lib/* /usr/lib 11) sudo cp -v ./arch/arm/boot/zImage /boot/zImage-4.10.0 12) sudo cp -v ./arch/arm/boot/dts/exynos5422-odroidxu4.dtb /boot/exynos5422-odroidxu4-4.10.0.dtb 13) sudo ln -s /boot/zImage-4.10.0 /boot/zImage 14) sudo ln -s /boot/exynos5422-odroidxu4-4.10.0.dtb /boot/exynos5422-odroidxu4.dtb 15) sudo sync 16) sudo systemctl reboot I've attached the config I use. On Mon, Mar 6, 2017 at 11:35 AM, Krzysztof Kozlowski wrote: > On Mon, Mar 06, 2017 at 10:18:45AM -0600, Nathan Royce wrote: >> I tried the patch you submitted, however it also fails for the most part. >> >> "For the most part" because "xts" is now found. >> $ grep xts /proc/crypto >> name : xts(aes) >> driver : xts(ecb-aes-s5p) > > Ah, so probably I did not fix the original issue but some other... or > maybe there are multiple issues. > > Could you attach your config and any other essential reproduction steps > (unusual settings?). > > I saw you tried v4.10.1, could you try just v4.10? > > Best regards, > Krzysztof > >> >> Fail: >> * >> [ 21.057756] xor: using function: neon (352.000 MB/sec) >> [ 21.064243] Unable to handle kernel NULL pointer dereference at >> virtual address 0004 >> [ 21.070966] pgd = c0004000 >> [ 21.073599] [0004] *pgd= >> [ 21.077165] Internal error: Oops: 17 [#1] SMP ARM >> [ 21.081836] Modules linked in: xor aes_arm xor_neon zlib_deflate >> raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc >> ip_tables x_tables >> [ 21.095239] CPU: 5 PID: 121 Comm: irq/69-1083 Not tainted >> 4.10.1-dirty #1 >> [ 21.102288] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) >> [ 21.108355] task: ee3e3700 task.stack: edcf6000 >> [ 21.112821] PC is at post_crypt+0x1b4/0x1c4 >> [ 21.116972] LR is at post_crypt+0x1a8/0x1c4 >> [ 21.121131] pc : []lr : []psr: 200c0093 >> [ 21.121131] sp : edcf7e68 ip : ec59dcf4 fp : 117ce9ac >> [ 21.132576] r10: 244525e3 r9 : c0c0540c r8 : ec59dc00 >> [ 21.137768] r7 : r6 : 0400 r5 : r4 : >> [ 21.144267] r3 : ef49fcde r2 : 0200 r1 : 0200 r0 : >> [ 21.150768] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM >> Segment none >> [ 21.157964] Control: 10c5387d Table: 6618c06a DAC: 0051 >> [ 21.163677] Process irq/69-1083 (pid: 121, stack limit = 0xedcf6218) >> [ 21.170350] Stack: (0xedcf7e68 to 0xedcf8000) >> [ 21.174684] 7e60: ef49fcdc ec93f200 ef49fcdc >> ec93f200 ec59dddc 0400 >> [ 21.182853] 7e80: 0400 ef49fcdc >> c01100fc >> [ 21.190983] 7ea0: c0110f80 0010 >> 0010 000f 00040a01 >> [ 21.199128] 7ec0: ec59dc00 c0c0540c >> 600c0013 0002 >> [ 21.207274] 7ee0: ee889d20 c033608c eea21c90 c05a80d0 eea21ce8 >> eea21c90 000c 00040a01 >> [ 21.215418] 7f00: eea21ce8 eea21c90 000c eea21ce8 >> c05a8290 0001 >> [ 21.223564] 7f20: eea2a600 eea8a400 eea8a400 eea2a600 c016ee68 >> c0c0540c c016ee84 >> [ 21.231710] 7f40: edcf6000 eea2a624 eea8a400 c016f198 eea2a640 >> c016ef7c 00040a01 >> [ 21.239868] 7f60: eeb58280 edcf6000 eea2a640 >> eea2a600 c016f04c eeb582a8 >> [ 21.248000] 7f80: ee889d20 c0138710 edcf6000 eea2a640 c0138608 >> >> [ 21.256145] 7fa0: c0107a38 >> >> [ 21.264291] 7fc0: >> >> [ 21.272428] 7fe0: 000
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Mon, Mar 06, 2017 at 10:18:45AM -0600, Nathan Royce wrote: > I tried the patch you submitted, however it also fails for the most part. > > "For the most part" because "xts" is now found. > $ grep xts /proc/crypto > name : xts(aes) > driver : xts(ecb-aes-s5p) Ah, so probably I did not fix the original issue but some other... or maybe there are multiple issues. Could you attach your config and any other essential reproduction steps (unusual settings?). I saw you tried v4.10.1, could you try just v4.10? Best regards, Krzysztof > > Fail: > * > [ 21.057756] xor: using function: neon (352.000 MB/sec) > [ 21.064243] Unable to handle kernel NULL pointer dereference at > virtual address 0004 > [ 21.070966] pgd = c0004000 > [ 21.073599] [0004] *pgd= > [ 21.077165] Internal error: Oops: 17 [#1] SMP ARM > [ 21.081836] Modules linked in: xor aes_arm xor_neon zlib_deflate > raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc > ip_tables x_tables > [ 21.095239] CPU: 5 PID: 121 Comm: irq/69-1083 Not tainted 4.10.1-dirty > #1 > [ 21.102288] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > [ 21.108355] task: ee3e3700 task.stack: edcf6000 > [ 21.112821] PC is at post_crypt+0x1b4/0x1c4 > [ 21.116972] LR is at post_crypt+0x1a8/0x1c4 > [ 21.121131] pc : []lr : []psr: 200c0093 > [ 21.121131] sp : edcf7e68 ip : ec59dcf4 fp : 117ce9ac > [ 21.132576] r10: 244525e3 r9 : c0c0540c r8 : ec59dc00 > [ 21.137768] r7 : r6 : 0400 r5 : r4 : > [ 21.144267] r3 : ef49fcde r2 : 0200 r1 : 0200 r0 : > [ 21.150768] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM > Segment none > [ 21.157964] Control: 10c5387d Table: 6618c06a DAC: 0051 > [ 21.163677] Process irq/69-1083 (pid: 121, stack limit = 0xedcf6218) > [ 21.170350] Stack: (0xedcf7e68 to 0xedcf8000) > [ 21.174684] 7e60: ef49fcdc ec93f200 ef49fcdc > ec93f200 ec59dddc 0400 > [ 21.182853] 7e80: 0400 ef49fcdc > c01100fc > [ 21.190983] 7ea0: c0110f80 0010 > 0010 000f 00040a01 > [ 21.199128] 7ec0: ec59dc00 c0c0540c > 600c0013 0002 > [ 21.207274] 7ee0: ee889d20 c033608c eea21c90 c05a80d0 eea21ce8 > eea21c90 000c 00040a01 > [ 21.215418] 7f00: eea21ce8 eea21c90 000c eea21ce8 > c05a8290 0001 > [ 21.223564] 7f20: eea2a600 eea8a400 eea8a400 eea2a600 c016ee68 > c0c0540c c016ee84 > [ 21.231710] 7f40: edcf6000 eea2a624 eea8a400 c016f198 eea2a640 > c016ef7c 00040a01 > [ 21.239868] 7f60: eeb58280 edcf6000 eea2a640 > eea2a600 c016f04c eeb582a8 > [ 21.248000] 7f80: ee889d20 c0138710 edcf6000 eea2a640 c0138608 > > [ 21.256145] 7fa0: c0107a38 > > [ 21.264291] 7fc0: > > [ 21.272428] 7fe0: 0013 > > [ 21.280580] [] (post_crypt) from [] > (decrypt_done+0x4c/0x54) > [ 21.287946] [] (decrypt_done) from [] > (s5p_aes_complete+0x70/0xfc) > [ 21.295845] [] (s5p_aes_complete) from [] > (s5p_aes_interrupt+0x134/0x1a0) > [ 21.304323] [] (s5p_aes_interrupt) from [] > (irq_thread_fn+0x1c/0x54) > [ 21.312378] [] (irq_thread_fn) from [] > (irq_thread+0x14c/0x204) > [ 21.320004] [] (irq_thread) from [] > (kthread+0x108/0x138) > [ 21.327109] [] (kthread) from [] > (ret_from_fork+0x14/0x3c) > [ 21.334300] Code: eb0114aa e598c118 e58d001c e1a04000 (e5906004) > [ 21.340363] ---[ end trace e87f375304ecdd42 ]--- > [ 21.344961] genirq: exiting task "irq/69-1083" (121) is an > active IRQ thread (irq 69) > [ 21.870157] irq 69: nobody cared (try booting with the "irqpoll" option) > [ 21.875435] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D > 4.10.1-dirty #1 > [ 21.883027] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > [ 21.889134] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [ 21.896826] [] (show_stack) from [] > (dump_stack+0x84/0x98) > [ 21.904015] [] (dump_stack) from [] > (__report_bad_irq+0x2c/0xcc) > [ 21.911716] [] (__report_bad_irq) from [] > (note_interrupt+0x28c/0x2dc) > [ 21.919948] [] (note_interrupt) from [] > (handle_irq_event_percpu+0x5c/0x7c) > [ 21.928614] [] (handle_irq_event_percpu) from > [] (handle_irq_event+0x38/0x5c) > [ 21.937451] [] (handle_irq_event) from [] > (handle_fasteoi_irq+0xb8/0x190) > [ 21.945944] [] (handle_fasteoi_irq) from [] > (generic_handle_irq+0x24/0x34) > [ 21.954522] [] (generic_handle_irq) from [] > (__handle_domain_irq+0x5c/0xb4) > [ 21.963188] [] (__handle_domain_irq) from [] > (gic_handle_irq+0x38/0x74) > [ 21.971505] [] (gic_handle_irq) from [] > (__irq_svc+0x6c/0x90)
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
I tried the patch you submitted, however it also fails for the most part. "For the most part" because "xts" is now found. $ grep xts /proc/crypto name : xts(aes) driver : xts(ecb-aes-s5p) Fail: * [ 21.057756] xor: using function: neon (352.000 MB/sec) [ 21.064243] Unable to handle kernel NULL pointer dereference at virtual address 0004 [ 21.070966] pgd = c0004000 [ 21.073599] [0004] *pgd= [ 21.077165] Internal error: Oops: 17 [#1] SMP ARM [ 21.081836] Modules linked in: xor aes_arm xor_neon zlib_deflate raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc ip_tables x_tables [ 21.095239] CPU: 5 PID: 121 Comm: irq/69-1083 Not tainted 4.10.1-dirty #1 [ 21.102288] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 21.108355] task: ee3e3700 task.stack: edcf6000 [ 21.112821] PC is at post_crypt+0x1b4/0x1c4 [ 21.116972] LR is at post_crypt+0x1a8/0x1c4 [ 21.121131] pc : []lr : []psr: 200c0093 [ 21.121131] sp : edcf7e68 ip : ec59dcf4 fp : 117ce9ac [ 21.132576] r10: 244525e3 r9 : c0c0540c r8 : ec59dc00 [ 21.137768] r7 : r6 : 0400 r5 : r4 : [ 21.144267] r3 : ef49fcde r2 : 0200 r1 : 0200 r0 : [ 21.150768] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none [ 21.157964] Control: 10c5387d Table: 6618c06a DAC: 0051 [ 21.163677] Process irq/69-1083 (pid: 121, stack limit = 0xedcf6218) [ 21.170350] Stack: (0xedcf7e68 to 0xedcf8000) [ 21.174684] 7e60: ef49fcdc ec93f200 ef49fcdc ec93f200 ec59dddc 0400 [ 21.182853] 7e80: 0400 ef49fcdc c01100fc [ 21.190983] 7ea0: c0110f80 0010 0010 000f 00040a01 [ 21.199128] 7ec0: ec59dc00 c0c0540c 600c0013 0002 [ 21.207274] 7ee0: ee889d20 c033608c eea21c90 c05a80d0 eea21ce8 eea21c90 000c 00040a01 [ 21.215418] 7f00: eea21ce8 eea21c90 000c eea21ce8 c05a8290 0001 [ 21.223564] 7f20: eea2a600 eea8a400 eea8a400 eea2a600 c016ee68 c0c0540c c016ee84 [ 21.231710] 7f40: edcf6000 eea2a624 eea8a400 c016f198 eea2a640 c016ef7c 00040a01 [ 21.239868] 7f60: eeb58280 edcf6000 eea2a640 eea2a600 c016f04c eeb582a8 [ 21.248000] 7f80: ee889d20 c0138710 edcf6000 eea2a640 c0138608 [ 21.256145] 7fa0: c0107a38 [ 21.264291] 7fc0: [ 21.272428] 7fe0: 0013 [ 21.280580] [] (post_crypt) from [] (decrypt_done+0x4c/0x54) [ 21.287946] [] (decrypt_done) from [] (s5p_aes_complete+0x70/0xfc) [ 21.295845] [] (s5p_aes_complete) from [] (s5p_aes_interrupt+0x134/0x1a0) [ 21.304323] [] (s5p_aes_interrupt) from [] (irq_thread_fn+0x1c/0x54) [ 21.312378] [] (irq_thread_fn) from [] (irq_thread+0x14c/0x204) [ 21.320004] [] (irq_thread) from [] (kthread+0x108/0x138) [ 21.327109] [] (kthread) from [] (ret_from_fork+0x14/0x3c) [ 21.334300] Code: eb0114aa e598c118 e58d001c e1a04000 (e5906004) [ 21.340363] ---[ end trace e87f375304ecdd42 ]--- [ 21.344961] genirq: exiting task "irq/69-1083" (121) is an active IRQ thread (irq 69) [ 21.870157] irq 69: nobody cared (try booting with the "irqpoll" option) [ 21.875435] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D 4.10.1-dirty #1 [ 21.883027] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 21.889134] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 21.896826] [] (show_stack) from [] (dump_stack+0x84/0x98) [ 21.904015] [] (dump_stack) from [] (__report_bad_irq+0x2c/0xcc) [ 21.911716] [] (__report_bad_irq) from [] (note_interrupt+0x28c/0x2dc) [ 21.919948] [] (note_interrupt) from [] (handle_irq_event_percpu+0x5c/0x7c) [ 21.928614] [] (handle_irq_event_percpu) from [] (handle_irq_event+0x38/0x5c) [ 21.937451] [] (handle_irq_event) from [] (handle_fasteoi_irq+0xb8/0x190) [ 21.945944] [] (handle_fasteoi_irq) from [] (generic_handle_irq+0x24/0x34) [ 21.954522] [] (generic_handle_irq) from [] (__handle_domain_irq+0x5c/0xb4) [ 21.963188] [] (__handle_domain_irq) from [] (gic_handle_irq+0x38/0x74) [ 21.971505] [] (gic_handle_irq) from [] (__irq_svc+0x6c/0x90) [ 21.978953] Exception stack(0xc0c01e68 to 0xc0c01eb0) [ 21.983975] 1e60: 00200102 c0c5cec0 0040 [ 21.992127] 1e80: c0c0 0001 c0c02080 c0c0 efffc7c0 c0c01f00 c0c01eb8 [ 22.000271] 1ea0: c0120b58 c01206d4 600e0113 [ 22.005299] [] (__irq_svc) from [] (__do_softirq+0x90/0x21c) [ 22.012667] [] (__do_softirq) from [] (irq_exit+0xd8/0x140) [ 22.019945] [] (irq_exit) from [] (__handle_domain_irq+0x60/0xb4) [ 22.027743] [] (__handle_domain_irq) from [] (gic_
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Fri, Mar 03, 2017 at 12:02:10PM +0800, Herbert Xu wrote: > On Thu, Mar 02, 2017 at 05:35:30PM -0600, Nathan Royce wrote: > > ARM ODroid XU4 > > > > $ cat /proc/config.gz | gunzip | grep XTS > > CONFIG_CRYPTO_XTS=y > > > > $ grep xts /proc/crypto > > //4.9.13 > > name : xts(aes) > > driver : xts(aes-generic) > > //4.10.1 > > > > //cbc can be found though > > > > CRYPTTAB: > > cryptswap1 UUID= /dev/urandom > > swap,offset=2048,cipher=aes-xts-plain64:sha512,size=512,nofail > > > > FSTAB: > > /dev/mapper/cryptswap1 none swap sw 0 0 > > > > Boot Log: > > [ 10.535985] [ cut here ] > > [ 10.539252] WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430 > > skcipher_walk_first+0x13c/0x14c > > [ 10.547542] Modules linked in: xor xor_neon aes_arm zlib_deflate > > dm_crypt raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc > > ip_tables x_tables > > [ 10.561716] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.1-dirty #1 > > [ 10.568049] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > > [ 10.574171] [] (unwind_backtrace) from [] > > (show_stack+0x10/0x14) > > [ 10.581893] [] (show_stack) from [] > > (dump_stack+0x84/0x98) > > [ 10.589073] [] (dump_stack) from [] > > (__warn+0xe8/0x100) > > [ 10.595975] [] (__warn) from [] > > (warn_slowpath_null+0x20/0x28) > > [ 10.603546] [] (warn_slowpath_null) from [] > > (skcipher_walk_first+0x13c/0x14c) > > [ 10.612390] [] (skcipher_walk_first) from [] > > (skcipher_walk_virt+0x1c/0x38) > > [ 10.621056] [] (skcipher_walk_virt) from [] > > (post_crypt+0x38/0x1c4) > > [ 10.629022] [] (post_crypt) from [] > > (decrypt_done+0x4c/0x54) > > [ 10.636389] [] (decrypt_done) from [] > > (s5p_aes_complete+0x70/0xfc) > > [ 10.644274] [] (s5p_aes_complete) from [] > > (s5p_aes_interrupt+0x134/0x1a0) > > [ 10.652771] [] (s5p_aes_interrupt) from [] > > (__handle_irq_event_percpu+0x9c/0x124) > > This looks like a bug in the s5p driver. It's calling the completion > function straight from the IRQ handler, which is triggering the > sanity check in skcipher_walk_first. > > The s5p driver needs to schedule a tasklet to call the completion > function. Tasklet... or threaded IRQ handler maybe? I sent a fix. BTW, I subscribe the crypto list but I could not find the original email there. Best regards, Krzysztof
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
Yup, when I disabled the s5p driver, xts DID show in the /proc/crypto list. Heh, I was about to ask if it was something I should push towards another maintainer for s5p stuff, but found you listed in that as well. If I am incorrect in that assumption, do let me know whom else I should make aware of this issue. Also let me know if you would like the rest of the kernel panic. Maybe you already have enough to go on and don't need it. Thanks for all that clarity. On Fri, Mar 3, 2017 at 6:04 AM, Herbert Xu wrote: > On Fri, Mar 03, 2017 at 04:36:18AM -0600, Nathan Royce wrote: >> I do have ECB selected as well: >> DM_CRYPT=y >> CRYPTO_ECB=y >> CRYPTO_XTS=y >> >> name : ecb(aes) >> driver : ecb-aes-s5p >> module : kernel >> priority : 100 >> refcnt : 1 >> selftest : passed >> internal : no >> type : ablkcipher >> async: yes >> blocksize: 16 >> min keysize : 16 >> max keysize : 32 >> ivsize : 0 >> geniv: >> //still no "xts" can be found in the list > > Weird. So you can't find any instances of xts in /proc/crypto > at all? Even if the self-test fails it should still register an > entry there... > > In any case, I think disabling the s5p driver should work at > least. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Fri, Mar 03, 2017 at 04:36:18AM -0600, Nathan Royce wrote: > I do have ECB selected as well: > DM_CRYPT=y > CRYPTO_ECB=y > CRYPTO_XTS=y > > name : ecb(aes) > driver : ecb-aes-s5p > module : kernel > priority : 100 > refcnt : 1 > selftest : passed > internal : no > type : ablkcipher > async: yes > blocksize: 16 > min keysize : 16 > max keysize : 32 > ivsize : 0 > geniv: > //still no "xts" can be found in the list Weird. So you can't find any instances of xts in /proc/crypto at all? Even if the self-test fails it should still register an entry there... In any case, I think disabling the s5p driver should work at least. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
I do have ECB selected as well: DM_CRYPT=y CRYPTO_ECB=y CRYPTO_XTS=y name : ecb(aes) driver : ecb-aes-s5p module : kernel priority : 100 refcnt : 1 selftest : passed internal : no type : ablkcipher async: yes blocksize: 16 min keysize : 16 max keysize : 32 ivsize : 0 geniv: //still no "xts" can be found in the list I saw this about the regression that sounds similar to my issue, except even when I built-in dm_crypt (no initramfs. just diving straight into system), it still fails: http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg23748.html On Fri, Mar 3, 2017 at 3:33 AM, Herbert Xu wrote: > On Fri, Mar 03, 2017 at 03:00:26AM -0600, Nathan Royce wrote: >> OK, I went ahead and enabled self tests >> "CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot, >> albeit with failures: >> * >> Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]--- >> Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on >> test 1 for xts(ecb-aes-s5p): ret=35 >> Mar 02 23:14:38 server kernel: device-mapper: table: 254:0: crypt: >> Error allocating crypto tfm >> Mar 02 23:14:38 server kernel: device-mapper: ioctl: error adding >> target to table >> Mar 02 23:14:39 server systemd-cryptsetup[234]: Failed to activate >> with key file '/dev/urandom': Invalid argument >> * >> (weird that it asked for the passphrase) >> >> But I do question whether the root issue is related to s5p... Maybe >> there is a correlation in the warning, but to me it looks like the >> issue is something else. > > I see. Do you have ECB enabled in your config? The new XTS requires > ECB to be present so that could be your problem. > > There is already a patch on its way to stable to add the Kconfig > select on ECB. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Fri, Mar 03, 2017 at 03:00:26AM -0600, Nathan Royce wrote: > OK, I went ahead and enabled self tests > "CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot, > albeit with failures: > * > Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]--- > Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on > test 1 for xts(ecb-aes-s5p): ret=35 > Mar 02 23:14:38 server kernel: device-mapper: table: 254:0: crypt: > Error allocating crypto tfm > Mar 02 23:14:38 server kernel: device-mapper: ioctl: error adding > target to table > Mar 02 23:14:39 server systemd-cryptsetup[234]: Failed to activate > with key file '/dev/urandom': Invalid argument > * > (weird that it asked for the passphrase) > > But I do question whether the root issue is related to s5p... Maybe > there is a correlation in the warning, but to me it looks like the > issue is something else. I see. Do you have ECB enabled in your config? The new XTS requires ECB to be present so that could be your problem. There is already a patch on its way to stable to add the Kconfig select on ECB. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
OK, I went ahead and enabled self tests "CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot, albeit with failures: * Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]--- Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on test 1 for xts(ecb-aes-s5p): ret=35 Mar 02 23:14:38 server kernel: device-mapper: table: 254:0: crypt: Error allocating crypto tfm Mar 02 23:14:38 server kernel: device-mapper: ioctl: error adding target to table Mar 02 23:14:39 server systemd-cryptsetup[234]: Failed to activate with key file '/dev/urandom': Invalid argument * (weird that it asked for the passphrase) But I do question whether the root issue is related to s5p... Maybe there is a correlation in the warning, but to me it looks like the issue is something else. In my OP, I noted that the xts crypto isn't even found in /proc/crypto in 4.10. I'd think it would at least be listed, even if it isn't used. CBC is listed in /proc/crypto with kernel 4.9.13 and 4.10.1 (cbc-aes-s5p) XTS is listed in /proc/crypto with kernel 4.9.13 but NOT 4.10.1 I should also add that I didn't include other tainted messages since they followed the messages I first posted. I was assuming that when the first issue would work, the others would follow suit. I just didn't want to inundate with possible junk. I still have the log file if you think it would be helpful to post the rest. PS: I also noticed the bounce from my first mail submission because I didn't enable plain-text for the e-mail (marked as spam because the email contained html). I rectified that for this reply. On Thu, Mar 2, 2017 at 10:02 PM, Herbert Xu wrote: > On Thu, Mar 02, 2017 at 05:35:30PM -0600, Nathan Royce wrote: >> ARM ODroid XU4 >> >> $ cat /proc/config.gz | gunzip | grep XTS >> CONFIG_CRYPTO_XTS=y >> >> $ grep xts /proc/crypto >> //4.9.13 >> name : xts(aes) >> driver : xts(aes-generic) >> //4.10.1 >> >> //cbc can be found though >> >> CRYPTTAB: >> cryptswap1 UUID= /dev/urandom >> swap,offset=2048,cipher=aes-xts-plain64:sha512,size=512,nofail >> >> FSTAB: >> /dev/mapper/cryptswap1 none swap sw 0 0 >> >> Boot Log: >> [ 10.535985] [ cut here ] >> [ 10.539252] WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430 >> skcipher_walk_first+0x13c/0x14c >> [ 10.547542] Modules linked in: xor xor_neon aes_arm zlib_deflate >> dm_crypt raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc >> ip_tables x_tables >> [ 10.561716] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.1-dirty #1 >> [ 10.568049] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) >> [ 10.574171] [] (unwind_backtrace) from [] >> (show_stack+0x10/0x14) >> [ 10.581893] [] (show_stack) from [] >> (dump_stack+0x84/0x98) >> [ 10.589073] [] (dump_stack) from [] >> (__warn+0xe8/0x100) >> [ 10.595975] [] (__warn) from [] >> (warn_slowpath_null+0x20/0x28) >> [ 10.603546] [] (warn_slowpath_null) from [] >> (skcipher_walk_first+0x13c/0x14c) >> [ 10.612390] [] (skcipher_walk_first) from [] >> (skcipher_walk_virt+0x1c/0x38) >> [ 10.621056] [] (skcipher_walk_virt) from [] >> (post_crypt+0x38/0x1c4) >> [ 10.629022] [] (post_crypt) from [] >> (decrypt_done+0x4c/0x54) >> [ 10.636389] [] (decrypt_done) from [] >> (s5p_aes_complete+0x70/0xfc) >> [ 10.644274] [] (s5p_aes_complete) from [] >> (s5p_aes_interrupt+0x134/0x1a0) >> [ 10.652771] [] (s5p_aes_interrupt) from [] >> (__handle_irq_event_percpu+0x9c/0x124) > > This looks like a bug in the s5p driver. It's calling the completion > function straight from the IRQ handler, which is triggering the > sanity check in skcipher_walk_first. > > The s5p driver needs to schedule a tasklet to call the completion > function. > > Do you have crypto self-test enabled? If so it should've caught > this at run-time. Otherwise you can disable the s5p driver until > it's fixed. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Thu, Mar 02, 2017 at 05:35:30PM -0600, Nathan Royce wrote: > ARM ODroid XU4 > > $ cat /proc/config.gz | gunzip | grep XTS > CONFIG_CRYPTO_XTS=y > > $ grep xts /proc/crypto > //4.9.13 > name : xts(aes) > driver : xts(aes-generic) > //4.10.1 > > //cbc can be found though > > CRYPTTAB: > cryptswap1 UUID= /dev/urandom > swap,offset=2048,cipher=aes-xts-plain64:sha512,size=512,nofail > > FSTAB: > /dev/mapper/cryptswap1 none swap sw 0 0 > > Boot Log: > [ 10.535985] [ cut here ] > [ 10.539252] WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430 > skcipher_walk_first+0x13c/0x14c > [ 10.547542] Modules linked in: xor xor_neon aes_arm zlib_deflate > dm_crypt raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc > ip_tables x_tables > [ 10.561716] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.1-dirty #1 > [ 10.568049] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > [ 10.574171] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [ 10.581893] [] (show_stack) from [] > (dump_stack+0x84/0x98) > [ 10.589073] [] (dump_stack) from [] > (__warn+0xe8/0x100) > [ 10.595975] [] (__warn) from [] > (warn_slowpath_null+0x20/0x28) > [ 10.603546] [] (warn_slowpath_null) from [] > (skcipher_walk_first+0x13c/0x14c) > [ 10.612390] [] (skcipher_walk_first) from [] > (skcipher_walk_virt+0x1c/0x38) > [ 10.621056] [] (skcipher_walk_virt) from [] > (post_crypt+0x38/0x1c4) > [ 10.629022] [] (post_crypt) from [] > (decrypt_done+0x4c/0x54) > [ 10.636389] [] (decrypt_done) from [] > (s5p_aes_complete+0x70/0xfc) > [ 10.644274] [] (s5p_aes_complete) from [] > (s5p_aes_interrupt+0x134/0x1a0) > [ 10.652771] [] (s5p_aes_interrupt) from [] > (__handle_irq_event_percpu+0x9c/0x124) This looks like a bug in the s5p driver. It's calling the completion function straight from the IRQ handler, which is triggering the sanity check in skcipher_walk_first. The s5p driver needs to schedule a tasklet to call the completion function. Do you have crypto self-test enabled? If so it should've caught this at run-time. Otherwise you can disable the s5p driver until it's fixed. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt