Re: Odroid HC1 cryptsetup:encrypt sata driver
Hi Kamil, On 30 January 2018 at 21:02, Kamil Konieczny <k.koniec...@partner.samsung.com> wrote: > Hi Anand, > > On 24.01.2018 14:04, Anand Moon wrote: >> Hi Kamil Konieczny, >> >> I am looking in setup of encrypted sata hard-disk on Odroid XU4/HC1 device. >> using following encryption method. >> >> aes-cbc-essiv:sha256 128 >> aes-cbc-essiv:sha256 256 >> >> Here is my defconfig I am using. https://pastebin.com/gF5T2stp >> >> Following crypt benchmark we use to test : https://pastebin.com/WiexsJA2 >> >> When I am trying to format the the hard drive I am getting kernel panic. >> I have tired different option like below. >> >> *Please guide me in how to fix this bug* >> [...] > > Sorry for late response, I was on holidays. Try latest kernel 4.15 > and turn off option: > > CONFIG_CRYPTO_DEV_EXYNOS_HASH=n > > in > > Cryptographic API: > Hardware crypto devices: > Support for Samsung Exynos HASH accelerator --> turn off > > You should also turn on option for software SHA256 (and maybe SHA1) > > This is last change in this driver, > so maybe there is some problem with concurrent access to hardware > by AES and HASH driver parts. > Thanks for your input, but I tried your suggestion on latest kernel. but the result is the same. How can I help trace this bug. please guide me. Best Regards -Anand > -- > Best regards, > Kamil Konieczny > Samsung R Institute Poland >
Re: Odroid HC1 cryptsetup:encrypt sata driver
Hi Kamil, On 2 February 2018 at 23:05, Kamil Konieczny <k.koniec...@partner.samsung.com> wrote: > > > On 24.01.2018 15:01, Krzysztof Kozlowski wrote: >> On Wed, Jan 24, 2018 at 2:04 PM, Anand Moon <linux.am...@gmail.com> wrote: >>> Hi Kamil Konieczny, >>> >>> I am looking in setup of encrypted sata hard-disk on Odroid XU4/HC1 device. >>> using following encryption method. >>> >>> aes-cbc-essiv:sha256 128 >>> aes-cbc-essiv:sha256 256 >>> >>> Here is my defconfig I am using. https://pastebin.com/gF5T2stp >>> >>> Following crypt benchmark we use to test : https://pastebin.com/WiexsJA2 >> >> No problems on my side with a 128 MB file (not a device): >> # cryptsetup -v luksFormat /tmp/testcrypt /dev/urandom >> --keyfile-size=32 --cipher aes-cbc-essiv:sha256 >> # Command successful. >> # cryptsetup -v luksFormat ~/testcrypt /dev/urandom --keyfile-size=32 >> --cipher aes-cbc-essiv:sha256 >> # Command successful. > > What version is cryptsetup ? > At my end I am using below version. root@odroid:~# cryptsetup --version cryptsetup 1.6.6 >> >> Linux 4.15.0-rc9-00023-g1f07476ec143. >> >> Some time ago you were building from not usual source code and your >> kernel version from WARN is not unambiguous. >> >> What is necessary to reproduce it? >>>[...] > > I get OOPS with cryptsetup 2.0.0, kernel 4.15 > I will try to get test with new version of cryptsetup 2.0.0. > If you have older cryptsetup, please keep it for reference. > > For now, I found that crypto-api or dm-crypt try to use aes-ecb > instead of aes-cbc, and sets req->info (pointer used for passing IV) to 0x10 > Ok. Best Regards -Anand > -- > Best regards, > Kamil Konieczny > Samsung R Institute Poland >
Re: [PATCH] crypto: s5p-sss.c: Fix kernel Oops in AES-ECB mode
Hi Kamil, Thanks for providing the fix to this issue. On 5 February 2018 at 23:10, Kamil Konieczny <k.koniec...@partner.samsung.com> wrote: > > In AES-ECB mode crypt is done with key only, so any use of IV > can cause kernel Oops, as reported by Anand Moon. If possible could you avoid the name in commit message. > Fixed it by using IV only in AES-CBC and AES-CTR. > > Signed-off-by: Kamil Konieczny <k.koniec...@partner.samsung.com> > Reported-by: Anand Moon <linux.am...@gmail.com> [snip] Please add my. Tested on Odroid HC2 Tested-by: Anand Moon <linux.am...@gmail.com> Below are the result at my end. aes-cbc-essiv:sha256 (128 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 11.7225 s, 71.6 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 22.112 s, 37.9 MB/s aes-cbc-essiv:sha256 (256 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 13.096 s, 64.1 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 24.4165 s, 34.4 MB/s aes-ctr-plain (128 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 11.2246 s, 74.7 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 20.426 s, 41.1 MB/s aes-xts-plain64 (256 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 11.1533 s, 75.2 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 20.8821 s, 40.2 MB/s aes-xts-plain64 (512 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 12.0614 s, 69.5 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 23.0717 s, 36.4 MB/s twofish-cbc-essiv:sha256 (128 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 13.031 s, 64.4 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 20.7202 s, 40.5 MB/s twofish-cbc-essiv:sha256 (256 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 12.9995 s, 64.5 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 24.2369 s, 34.6 MB/s twofish-xts-plain64 (256 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 14.607 s, 57.4 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 26.2963 s, 31.9 MB/s twofish-xts-plain64 (512 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 14.5783 s, 57.5 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 25.3593 s, 33.1 MB/s serpent-cbc-essiv:sha256 (128 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 15.5157 s, 54.1 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 37.0526 s, 22.6 MB/s serpent-cbc-essiv:sha256 (256 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 16.1138 s, 52.1 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 36.922 s, 22.7 MB/s serpent-xts-plain64 (256 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 17.287 s, 48.5 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 39.279 s, 21.4 MB/s serpent-xts-plain64 (512 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 16.9464 s, 49.5 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 38.3389 s, 21.9 MB/s Best Regards -Anand
Re: [PATCH] crypto: s5p-sss.c: Fix kernel Oops in AES-ECB mode
Hi Kamil On 6 February 2018 at 22:40, Kamil Konieczny <k.koniec...@partner.samsung.com> wrote: > > On 06.02.2018 17:48, Anand Moon wrote: >> Hi Kamil, >> >> Thanks for providing the fix to this issue. >> >> On 5 February 2018 at 23:10, Kamil Konieczny >> <k.koniec...@partner.samsung.com> wrote: >>> >>> In AES-ECB mode crypt is done with key only, so any use of IV >>> can cause kernel Oops, as reported by Anand Moon. >> >> If possible could you avoid the name in commit message. > > This is added after '---' line, so it will not appear in commit message. > I know about '---' delimiter, but to be precise this will be part of commit message. >>> Fixed it by using IV only in AES-CBC and AES-CTR. >>> >>> Signed-off-by: Kamil Konieczny <k.koniec...@partner.samsung.com> >>> Reported-by: Anand Moon <linux.am...@gmail.com> >> >> [snip] >> >> Please add my. Tested on Odroid HC2 >> >> Tested-by: Anand Moon <linux.am...@gmail.com> > > This will add you name in commit message, > additionally with 'Reported-by:' line. > >> Below are the result at my end. >> >> aes-cbc-essiv:sha256 (128 bit key) >> WRITE: >> 100+0 records in >> 100+0 records out >> 838860800 bytes (839 MB, 800 MiB) copied, 11.7225 s, 71.6 MB/s >> [...] > > is it from 'cryptsetup benchmark' ? benchmark did not cause oops. > Please test with luksFormat, ie. use > > cryptsetup luksFormat --debug -q -d /tmp/testkey.key \ > --cipher aes-cbc-essiv:sha256 -h sha256 -s 128 /tmp/test.bin > [snip] Below is the out put of aes-cbc-essiv:sha256 and aes-ctr-plain root@odroid:~# fallocate -l 128MiB /tmp/test.bin root@odroid:~# dd if=/dev/urandom of=/tmp/testkey.key bs=128 count=1 1+0 records in 1+0 records out 128 bytes copied, 0.000231043 s, 554 kB/s root@odroid:~# sync root@odroid:~# cryptsetup luksFormat --debug -q -d /tmp/testkey.key \ > --cipher aes-cbc-essiv:sha256 -h sha256 -s 128 /tmp/test.bin # cryptsetup 1.6.6 processing "cryptsetup luksFormat --debug -q -d /tmp/testkey.key --cipher aes-cbc-essiv:sha256 -h sha256 -s 128 /tmp/test.bin" # Running command luksFormat. # Locking memory. # Installing SIGINT/SIGTERM handler. # Unblocking interruption on signal. # Allocating crypt device /tmp/test.bin context. # Trying to open and read device /tmp/test.bin. # Initialising device-mapper backend library. # Timeout set to 0 miliseconds. # Iteration time set to 1000 miliseconds. # File descriptor passphrase entry requested. # Formatting device /tmp/test.bin as type LUKS1. # Crypto backend (gcrypt 1.6.5) initialized. # Detected kernel Linux 4.15.0-xu4krck armv7l. # Topology info for /tmp/test.bin not supported, using default offset 1048576 bytes. # Checking if cipher aes-cbc-essiv:sha256 is usable. # Using userspace crypto wrapper to access keyslot area. # Generating LUKS header version 1 using hash sha256, aes, cbc-essiv:sha256, MK 16 bytes # KDF pbkdf2, hash sha256: 160824 iterations per second. # Data offset 2048, UUID fe5c0d54-9add-4454-a4cd-98eed8f2b75c, digest iterations 19625 # Updating LUKS header of size 1024 on device /tmp/test.bin # Key length 16, device size 262144 sectors, header size 1029 sectors. # Reading LUKS header of size 1024 from device /tmp/test.bin # Key length 16, device size 262144 sectors, header size 1029 sectors. # Adding new keyslot -1 using volume key. # Calculating data for key slot 0 # KDF pbkdf2, hash sha256: 161220 iterations per second. # Key slot 0 use 78720 password iterations. # Using hash sha256 for AF in key slot 0, 4000 stripes # Updating key slot 0 [0x1000] area. # Using userspace crypto wrapper to access keyslot area. # Key slot 0 was enabled in LUKS header. # Updating LUKS header of size 1024 on device /tmp/test.bin # Key length 16, device size 262144 sectors, header size 1029 sectors. # Reading LUKS header of size 1024 from device /tmp/test.bin # Key length 16, device size 262144 sectors, header size 1029 sectors. # Releasing crypt device /tmp/test.bin context. # Releasing device-mapper backend. # Unlocking memory. Command successful. root@odroid:~# root@odroid:~# root@odroid:~# fallocate -l 128MiB /tmp/test.bin root@odroid:~# dd if=/dev/urandom of=/tmp/testkey.key bs=128 count=1 1+0 records in 1+0 records out 128 bytes copied, 0.000324001 s, 395 kB/s root@odroid:~# sync root@odroid:~# cryptsetup luksFormat --debug -q -d /tmp/testkey.key \ > --cipher aes-ctr-plain -h sha256 -s 128 /tmp/test.bin # cryptsetup 1.6.6 processing "cryptsetup luksFormat --debug -q -d /tmp/testkey.key --cipher aes-ctr-plain -h sha256 -s 128 /tmp/test.bin" # Running command luksFormat. # Locking memory. # Installing SIGINT/SIGTERM handler. # Unblocking interruption on signal. # Allocating crypt device /tmp/test.bin context. # Trying to open an
Odroid HC1 cryptsetup:encrypt sata driver
Hi Kamil Konieczny, I am looking in setup of encrypted sata hard-disk on Odroid XU4/HC1 device. using following encryption method. aes-cbc-essiv:sha256 128 aes-cbc-essiv:sha256 256 Here is my defconfig I am using. https://pastebin.com/gF5T2stp Following crypt benchmark we use to test : https://pastebin.com/WiexsJA2 When I am trying to format the the hard drive I am getting kernel panic. I have tired different option like below. *Please guide me in how to fix this bug* # cryptsetup luksFormat /dev/sda1 --cipher aes-cbc-essiv:sha256 # cryptsetup --cipher aes-cbc-essiv --hash sha256 --use-urandom --key-file=/dev/urandom --master-key-file=/dev/urandom --keyfile-size=256 --key-size=256 luksFormat /dev/sda1 [kernel panic]- root@odroid:~# cryptsetup luksFormat /dev/sda1 --cipher aes-cbc-essiv:sha256 WARNING! This will overwrite data on /dev/sda1 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: [ 2078.670930] Unable to handle kernel NULL pointer dereference at virtual address 0010 [ 2078.677550] pgd = b0cb4e51 [ 2078.680220] [0010] *pgd= [ 2078.683779] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 2078.689148] Modules linked in: algif_skcipher af_alg sd_mod sg evdev uas usb_storage scsi_mod gpio_keys fbtft(C) spidev spi_s3c64xx ipv6 [ 2078.701377] CPU: 1 PID: 15 Comm: ksoftirqd/1 Tainted: G C 4.15.0-rc9-xu4krck #1 [ 2078.709861] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 2078.715932] PC is at memcpy+0x80/0x330 [ 2078.719652] LR is at s5p_tasklet_cb+0x19c/0x328 [ 2078.724155] pc : []lr : []psr: 00070093 [ 2078.730396] sp : ee917ebc ip : 0010 fp : ee8cbe30 [ 2078.735594] r10: 0007 r9 : r8 : 60070013 [ 2078.740794] r7 : e7812fc4 r6 : ee23a268 r5 : 0020 r4 : ee23a210 [ 2078.747294] r3 : e7812fc0 r2 : fff0 r1 : 0010 r0 : f1a6b230 [ 2078.753794] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none [ 2078.760986] Control: 10c5387d Table: 6d6b006a DAC: 0051 [ 2078.766705] Process ksoftirqd/1 (pid: 15, stack limit = 0x2572141a) [ 2078.772944] Stack: (0xee917ebc to 0xee918000) [ 2078.777276] 7ea0: 0020 [ 2078.785426] 7ec0: ee23a268 e7812fc4 60070013 f1a6b230 ee23a210 c06f48b0 ee23a23c ee23a240 [ 2078.793578] 7ee0: c0c7d29c 0100 0007 c012ad88 c0d03098 0006 [ 2078.801723] 7f00: ee916000 c0d93948 0040 c010159c c09030a8 ee917f64 ee917f10 [ 2078.809866] 7f20: c0d03080 c0dab3c0 000a 0006c904 c0d03d00 04208040 ee8afa40 e000 [ 2078.818012] 7f40: ee8afa40 c0d0c718 e000 ee8afb1c ee8cbe30 c012a550 [ 2078.826157] 7f60: ee916000 c0146eac ee8afb00 ee8afac0 ee916000 ee8afa40 c0146d5c [ 2078.834303] 7f80: ee8afb1c c0142ff4 ee8afac0 c0142ed0 [ 2078.842448] 7fa0: c01088e8 [ 2078.850593] 7fc0: [ 2078.858739] 7fe0: 0013 0040 00080008 [ 2078.866894] [] (memcpy) from [] (s5p_tasklet_cb+0x19c/0x328) [ 2078.874255] [] (s5p_tasklet_cb) from [] (tasklet_action+0x58/0xe4) [ 2078.882140] [] (tasklet_action) from [] (__do_softirq+0x114/0x3b0) [ 2078.890023] [] (__do_softirq) from [] (run_ksoftirqd+0x3c/0x64) [ 2078.897650] [] (run_ksoftirqd) from [] (smpboot_thread_fn+0x150/0x268) [ 2078.905884] [] (smpboot_thread_fn) from [] (kthread+0x124/0x154) [ 2078.913596] [] (kthread) from [] (ret_from_fork+0x14/0x2c) [ 2078.920784] Code: e320f000 e4913004 e4914004 e4915004 (e4916004) [ 2078.926846] ---[ end trace 025fbaef2835f80b ]--- [ 2078.931435] Kernel panic - not syncing: Fatal exception in interrupt [ 2078.937781] CPU2: stopping [ 2078.940450] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G D C 4.15.0-rc9-xu4krck #1 [ 2078.948684] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 2078.954757] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 2078.962467] [] (show_stack) from [] (dump_stack+0x84/0x98) [ 2078.969659] [] (dump_stack) from [] (handle_IPI+0x334/0x3a8) [ 2078.977022] [] (handle_IPI) from [] (gic_handle_irq+0x98/0x9c) [ 2078.984561] [] (gic_handle_irq) from [] (__irq_svc+0x6c/0xa8) [ 2078.992010] Exception stack(0xee8fdf68 to 0xee8fdfb0) [ 2078.997035] df60: 0001 c011be00 ee8fc000 c0d04d6c [ 2079.005185] df80: c0d04dbc 0004 c0c84870 ee8fdfc0 2e117000 ee8fdfb8 [ 2079.013328] dfa0: c0109358 c010935c 600e0013 [ 2079.018354] [] (__irq_svc) from [] (arch_cpu_idle+0x38/0x3c) [ 2079.025725] [] (arch_cpu_idle) from [] (do_idle+0x184/0x218) [ 2079.033089] [] (do_idle) from [] (cpu_startup_entry+0x18/0x1c) [ 2079.040627] [] (cpu_startup_entry) from [<401018cc>] (0x401018cc) [ 2079.047554] CPU3: stopping [ 2079.050240] CPU: 3 PID: 0 Comm: swapper/3
Re: Odroid HC1 cryptsetup:encrypt sata driver
Hi Krzysztof, On 24 January 2018 at 19:31, Krzysztof Kozlowski <k...@kernel.org> wrote: > On Wed, Jan 24, 2018 at 2:04 PM, Anand Moon <linux.am...@gmail.com> wrote: >> Hi Kamil Konieczny, >> >> I am looking in setup of encrypted sata hard-disk on Odroid XU4/HC1 device. >> using following encryption method. >> >> aes-cbc-essiv:sha256 128 >> aes-cbc-essiv:sha256 256 >> >> Here is my defconfig I am using. https://pastebin.com/gF5T2stp >> >> Following crypt benchmark we use to test : https://pastebin.com/WiexsJA2 > > No problems on my side with a 128 MB file (not a device): > # cryptsetup -v luksFormat /tmp/testcrypt /dev/urandom > --keyfile-size=32 --cipher aes-cbc-essiv:sha256 > # Command successful. > # cryptsetup -v luksFormat ~/testcrypt /dev/urandom --keyfile-size=32 > --cipher aes-cbc-essiv:sha256 > # Command successful. > > Linux 4.15.0-rc9-00023-g1f07476ec143. > > Some time ago you were building from not usual source code and your > kernel version from WARN is not unambiguous. > > What is necessary to reproduce it? [snip] I am build the latest kernel I have check you [0] https://github.com/krzk/tools testcase it pass. To reproduce the issue you need to run. [1] crypto benchmark shell script https://pastebin.com/WiexsJA2 If we leave out below testcase case most of the test case passes with hard-drive or /tmp/testcontainer.bin aes-cbc-essiv:sha256 128 aes-cbc-essiv:sha256 256 Below is the command form the testcase which fails. + [[ ! -e /tmp/testcontainer.bin ]] + fallocate -l 939524096 /tmp/testcontainer.bin + [[ ! -e /tmp/testkey.key ]] + dd if=/dev/urandom of=/tmp/testkey.key bs=512 count=1 1+0 records in 1+0 records out 512 bytes copied, 0.000123042 s, 4.2 MB/s + sync + [[ ! -d /mnt ]] + trap control_c EXIT + test_cipher aes-cbc-essiv:sha256 128 + local cipher=aes-cbc-essiv:sha256 + local keysize=128 + echo '' + echo 'aes-cbc-essiv:sha256 (128 bit key)' aes-cbc-essiv:sha256 (128 bit key) + cryptsetup luksFormat -q -d /tmp/testkey.key --cipher aes-cbc-essiv:sha256 -h sha512 -s 128 /tmp/testcontainer.bin with kernel panic. Best Regards -Anand
