2.6.30-rc8 cryptsetup support

[micky]

Hi,

I'm currently using the default kernel which supports cryptsetup. Now I tried to boot from a USB stick using the 2.6.30-rc8 kernel. As it does not include SHA256 and device mapper support, I downloaded the config from http://sheeva.with-linux.com/sheeva/ added both and recompiled kernel and modules.

Using this compiled kernel, after entering the passphrase I get a NULL pointer exception. I'm not sure if I missed another module or if this is a bug in the kernel sources (current git version from git://git.marvell.com/orion.git).

I'm using the default cipher aes-cbc-essiv:sha256 (cryptsetup luksOpen /dev/sda s)

Did any of you ever use cryptsetup on the 2.6.30-rc8 kernel? Any hints on the exception below?

Is cryptsetup already using the hardware aes?

Code:

kernel BUG at kernel/workqueue.c:191!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = de99c000
[00000000] *pgd=1f244031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1] PREEMPT
Modules linked in: dm_crypt dm_mod ipv6
CPU: 0    Not tainted  (2.6.30-04051-gd51634f #4)
PC is at _etext+0xffc1dd0c/0x1db30
LR is at _etext+0xffc30f88/0x1db30
pc : [<c002ed0c>]    lr : [<c0041f88>]    psr: 40000013
sp : df38db50  ip : df38daa8  fp : df38db5c
r10: de81c000  r9 : e0bf7020  r8 : 00000000
r7 : df947e00  r6 : de81c000  r5 : de8ca560  r4 : de939000
r3 : 00000000  r2 : df38c000  r1 : df38daa8  r0 : 00000029
Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005317f  Table: 1e99c000  DAC: 00000015
Process cryptsetup (pid: 1775, stack limit = 0xdf38c270)
---[ end trace 1531ce7cf72b88dd ]---
note: cryptsetup[1775] exited with preempt_count 1
BUG: scheduling while atomic: cryptsetup/1775/0x40000002
Modules linked in: dm_crypt dm_mod ipv6
[<c00309c0>] (_etext+0xffc1f9c0/0x1db30) from [<c037296c>] (_etext+0xfff6196c/0x1db30)
[<c037296c>] (_etext+0xfff6196c/0x1db30) from [<c0039be0>] (_etext+0xffc28be0/0x1db30)
[<c0039be0>] (_etext+0xffc28be0/0x1db30) from [<c03732c0>] (_etext+0xfff622c0/0x1db30)
[<c03732c0>] (_etext+0xfff622c0/0x1db30) from [<c00a14f4>] (_etext+0xffc904f4/0x1db30)
[<c00a14f4>] (_etext+0xffc904f4/0x1db30) from [<c00a2918>] (_etext+0xffc91918/0x1db30)
[<c00a2918>] (_etext+0xffc91918/0x1db30) from [<c003ed14>] (_etext+0xffc2dd14/0x1db30)
[<c003ed14>] (_etext+0xffc2dd14/0x1db30) from [<c0042c4c>] (_etext+0xffc31c4c/0x1db30)
[<c0042c4c>] (_etext+0xffc31c4c/0x1db30) from [<c004430c>] (_etext+0xffc3330c/0x1db30)
[<c004430c>] (_etext+0xffc3330c/0x1db30) from [<c002f168>] (_etext+0xffc1e168/0x1db30)
[<c002f168>] (_etext+0xffc1e168/0x1db30) from [<c0031a10>] (_etext+0xffc20a10/0x1db30)
[<c0031a10>] (_etext+0xffc20a10/0x1db30) from [<c0376ac4>] (_etext+0xfff65ac4/0x1db30)
[<c0376ac4>] (_etext+0xfff65ac4/0x1db30) from [<c002b24c>] (_etext+0xffc1a24c/0x1db30)
[<c002b24c>] (_etext+0xffc1a24c/0x1db30) from [<c0374b8c>] (_etext+0xfff63b8c/0x1db30)
Exception stack(0xdf38db08 to 0xdf38db50)
db00:                   00000029 df38daa8 df38c000 00000000 de939000 de8ca560
db20: de81c000 df947e00 00000000 e0bf7020 de81c000 df38db5c df38daa8 df38db50
db40: c0041f88 c002ed0c 40000013 ffffffff
[<c0374b8c>] (_etext+0xfff63b8c/0x1db30) from [<c0041f88>] (_etext+0xffc30f88/0x1db30)

Thanks
Michael

[micky]

Isn't anyone using cryptsetup on the current release candidate? I really would like to update to 2.6.30... 

[kilowatt]

I would like to get this working for my rsync over ssh that I use to sync up the server at my home and vacation home.  I suspect the limitation on the rsync through put is the ssh encryption.

Unfortunately I don't know even know where to start to enable using the encryption engine for ssh.  I've goggled a bit but have not tried real seriously yet.

I would be glad to help out getting this working if someone knows the basic setup needed to make this happen.

Mark

[micky]

A short benchmark without and with aes encryption through cryptsetup. I just don't know if it's already using the hardware AES or not. The 2.6.30-rc8 includes the hardware AES driver, but obviously no one here is using cryptsetup and I'm no kernel expert.
 

Code:

/dev/sda:
 Timing cached reads:   422 MB in  2.00 seconds = 210.60 MB/sec
 Timing buffered disk reads:   92 MB in  3.04 seconds =  30.21 MB/sec
root@sheeva:~# hdparm -tT /dev/mapper/speicher

/dev/mapper/speicher:
 Timing cached reads:   410 MB in  2.01 seconds = 204.47 MB/sec
 Timing buffered disk reads:   50 MB in  3.06 seconds =  16.35 MB/sec
root@sheeva:~#

[rshitrit]

The support for the orion crypto is only for 5182 not for 6281 (the plug u are using).
the crypto support on LSP based on 2.6.22 is by using external package (OCF) and special dm-crypt patch developed by Marvell...

[DozenCrows]

Regarding the original post - I'm trying to set up an encrypted file system within a file using cryptmount on 2.6.30.1 and am seeing what looks like the same crash:

Code:

kernel BUG at kernel/workqueue.c:192!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = dea34000
[00000000] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT
Modules linked in: dm_crypt dm_mod ipv6
CPU: 0    Not tainted  (2.6.30.1 #2)
PC is at __bug+0x20/0x2c
LR is at vprintk+0x34c/0x39c
pc : [<c002ed0c>]    lr : [<c003e8e8>]    psr: 40000013
sp : dea51b38  ip : dea51a90  fp : dea51b44
r10: 00000000  r9 : e0c95020  r8 : 003e7c14
r7 : df3bad80  r6 : de951000  r5 : df19bc40  r4 : df3ebe70
r3 : 00000000  r2 : dea50000  r1 : dea51a90  r0 : 00000029
Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005317f  Table: 1ea34000  DAC: 00000015
Process vol_id (pid: 2398, stack limit = 0xdea50268)
...

I have the same issue with 2.6.30-rc6. I tried previously with the stock Sheeva kernel from the onboard flash but couldn't make cryptmount get this far possibly because of lack of support for loopback devices or the device mapper.

One test I have tried is to set up /dev/loop0 with the file intended to contain my encrypted file system - this seems to attach and detach fine. My theory is that something in dmcrypt is possibly falling over? Or the kernel config is wrong; this kernel was supplied by cbxbiker61 from here http://sheeva.with-linux.com/sheeva/. And I'm using it as-is without any further patches or rebuilding.

[DozenCrows]

Just done a little more testing, carrying out the loopback device setup and dmsetup by hand like this (assumes loop device file is set up):

Code:

# sudo losetup /dev/loop0 /home/user/file_to_contain_file_system
# echo 0 `sudo blockdev --getsize /dev/loop0` crypt aes 9347ef2d003de8e74aafecbd40985b613d73af7f79adf7b537b9042d7a911210 0 /dev/loop0 0 | sudo dmsetup create encrypted

And the crash happens on running dmsetup. Any subsequent attempt to remove the device gives this (requiring a reboot to restore things to normal):

Code:

# sudo dmsetup remove encrypted
device-mapper: remove ioctl failed: Device or resource busy
Command failed

Are there any Marvell folks or kernel gurus reading this out there who might be able to shed light for us lesser mortals?

This looks to be easy to reproduce.

[micky]

I compiled my kernel based on the same configuration (last try with the 2.6.30 tag sources) but added modules I thought are neccessary (device-mapper, aesXXX, loop devices). Didn't work anyway.
I have no experience in this but I would expect a clearer error messages if a required module was missing than the expection shown above.

[calamari]

micky, did you ever get this to run? I just tried the 2.6.30.5 kernel, but I'm getting a segfault that might be related.

[micky]

I have given up. I'm still running the old system that came with the box. I'd really like to update to some extra modules but I don't have a clue how to fix this. There weren't many replies, probably not many people are using encryption at all.

It also seems that the old version supports the hardware encryption, while the newer ones from this site dont (see post from rshitrit).

[calamari]

Good news: I've compiled 2.6.31-rc6 and cryptsetup seems to work nicely again. However I don't know if it's using hardware acceleration or not.

First I tried  2.6.31-rc8, but had the issue that cryptsetup seemed to hang when issuing the luksOpen command. Actually it did open my partition when pressing Ctrl-C twice after a while -- this might be related to the bug described here, which was introduced in 2.6.31-rc7 apparently.

Regarding the compilation itself, I followed the guide here and there, together with a slightly modified version of cbxbiker61's script.

[micky]

That's great news! I'll give it a try as soon as I find the time (within the next 3 weeks I guess).

Could you please post details on the script you used or even the script itself? I guess you started on the newest one (http://sheeva.with-linux.com/sheeva/2.6.30.5/sheeva-2.6.30.5.config). What changes did you make?
Did you use the Marvell or the kernel.org sources? Did you apply any of the patches from sheeva.with-linux.com/sheeva/2.6.30.5?

As you tried a new release candidate it seems the problem has been fixed somewhere between 2.8.30 and 2.8.31.

[calamari]

First I compiled the kernel (from kernel.org) with only the default settings, except for enabling dm-crypt, and without any patches. This worked well, but I guess it's probably better to use the more extended configuration and apply the patches.

That's why later I used cbxbiker61's 2.6.30.5 kernel configuration you mentioned. I also enabled the crypto loop device and crypto hardware drivers (though I have no idea if that driver is suited for the sheevaplug). In addition I applied those patches that worked without problems (some don't seem to be necessary anymore).

I uploaded the binaries to my sheeva plug  , so if you want to try it, just download it here: README-2.6.31-rc6. It should work like cbxbiker61's scripts.

cbxbiker61, could you maybe host this, so there's a single location for the prebuilt kernels? Or maybe you could also support the 2.6.31 release candidates? That would be awesome.

[calamari]

Just for fun I also checked out the orion repository and built the kernel. This now even includes the crypto hardware acceleration module. However I'm not sure if that's really active or not. Strangely, after entering your passphrase and pressing enter, cryptsetup seems to hang. Yet when you're pressing Ctrl-C it finishes successfully.

I've put a script here: README-2.6.31-rc7-00165-g97f6ce5.

[calamari]

Small update: the orion build (2.6.31-rc7) above now also includes a patch I found here that fixes the following kernel warnings:

Code:

Aug 30 15:05:14 sheevaplug kernel: ------------[ cut here ]------------
Aug 30 15:05:14 sheevaplug kernel: WARNING: at arch/arm/kernel/process.c:171 cpu_idle+0x78/0xc0()
Aug 30 15:05:14 sheevaplug kernel: Modules linked in: cbc sg dm_crypt dm_mod
Aug 30 15:05:14 sheevaplug kernel: [<c002a7fc>] (unwind_backtrace+0x0/0xd8) from [<c00393c4>] (warn_slowpath_common+0x48/0x60)
Aug 30 15:05:14 sheevaplug kernel: [<c00393c4>] (warn_slowpath_common+0x48/0x60) from [<c0026920>] (cpu_idle+0x78/0xc0)
Aug 30 15:05:14 sheevaplug kernel: [<c0026920>] (cpu_idle+0x78/0xc0) from [<c0008a74>] (start_kernel+0x22c/0x274)
Aug 30 15:05:14 sheevaplug kernel: [<c0008a74>] (start_kernel+0x22c/0x274) from [<00008034>] (0x8034)
Aug 30 15:05:14 sheevaplug kernel: ---[ end trace 58552e5ab72ed769 ]---