Re: Odroid HC1 cryptsetup:encrypt sata driver

[Anand Moon]

Hi Kamil,

On 2 February 2018 at 23:05, Kamil Konieczny
 wrote:
>
>
> On 24.01.2018 15:01, Krzysztof Kozlowski wrote:
>> On Wed, Jan 24, 2018 at 2:04 PM, 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
>>
>> 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: Odroid HC1 cryptsetup:encrypt sata driver

[Kamil Konieczny]

On 24.01.2018 15:01, Krzysztof Kozlowski wrote:
> On Wed, Jan 24, 2018 at 2:04 PM, 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
> 
> 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 ?

> 
> 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

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

-- 
Best regards,
Kamil Konieczny
Samsung R Institute Poland

Re: Odroid HC1 cryptsetup:encrypt sata driver

[Kamil Konieczny]

On 31.01.2018 06:51, Anand Moon wrote:
> Hi Kamil,
> 
> On 30 January 2018 at 21:02, Kamil Konieczny
>  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:
>> [...]
> 
> 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.

I was able to reproduce this bug with latest kernel 4.15 on Odroid HC1,
I am debugging it now.
Thank you for reporting it.

-- 
Best regards,
Kamil Konieczny
Samsung R Institute Poland

Re: Odroid HC1 cryptsetup:encrypt sata driver

[Anand Moon]

Hi Kamil,

On 30 January 2018 at 21:02, Kamil Konieczny
 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

[Kamil Konieczny]

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.

-- 
Best regards,
Kamil Konieczny
Samsung R Institute Poland

Re: Odroid HC1 cryptsetup:encrypt sata driver

[Anand Moon]

Hi Krzysztof,

On 24 January 2018 at 19:31, Krzysztof Kozlowski  wrote:
> On Wed, Jan 24, 2018 at 2:04 PM, 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
>
> 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

Re: Odroid HC1 cryptsetup:encrypt sata driver

[Krzysztof Kozlowski]

On Wed, Jan 24, 2018 at 2:04 PM, 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

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?

Best regards,
Krzysztof


>
> 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 []
>