[Pkg-cryptsetup-devel] Bug#403426: kernel corrupts LUKS partition header on arm

[Gordon Farquharson]

On 1/4/07, Martin Michlmayr <tbm at cyrius.com> wrote:

> * Clemens Fruhwirth <clemens at endorphin.org> [2007-01-04 12:56]:
> > So, can we close the bug against cryptsetup in this case?
>
> #403426 is really about the header corruption which you have fixed in
> SVN.  It should be closed when the Debian maintainers make a new
> upload with that fix.
>
> > Maybe someone else can verify that?
>
> CCing Gordon. :)

Ok, so here are some interesting results...

I am able to access the LUKS partition on the NSLU2 running 2.6.18
from subversion (which includes flush_anon_page-generic.patch and
flush_anon_page-arm.patch) with both cryptsetup-1.0.4-8 (the latest
version in testing) and cryptsetup-1.0.4-8 plus 02_fix_arm.dpatch and
03_no_header_conv.dpatch that were posted to this thread.

$ sudo cryptsetup luksOpen /dev/sdb3 testfs
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
gordon at LKG7102D7:~$ sudo mount /dev/mapper/testfs /mnt/tmp
gordon at LKG7102D7:~$ sudo umount /mnt/tmp
gordon at LKG7102D7:~$ sudo cryptsetup luksClose testfs

However, I have found that I am unable to access the LUKS partition
when the system is under heavy load and swapping.

$ sudo cryptsetup luksOpen /dev/sdb3 testfs
Enter LUKS passphrase:
Enter LUKS passphrase:
Enter LUKS passphrase:
Command failed: No key available with this passphrase.

gordon at LKG7102D7:~$ uptime
 00:22:23 up 16 min,  2 users,  load average: 3.01, 1.85, 0.93
gordon at LKG7102D7:~$ free
             total       used       free     shared    buffers     cached
Mem:         29988      28908       1080          0        172       3028
-/+ buffers/cache:      25708       4280
Swap:        88316      67508      20808

Once the system load decreases and the swapping stops, I am able to
access the LUKS partition again. This behaviour is very repeatable.

Martin, I wonder if this has anything to do with the virtual memory
bug in the kernel that we experienced with apt. It could be that this
bug existed before 2.6.19 but was much harder to trigger (e.g. see
http://lkml.org/lkml/2007/1/3/285). It would be interesting to try
accessing a LUKS partition under heavy load while running 2.6.20-git,
but that will have to wait until the weekend for me to test it.

Gordon

-- 
Gordon Farquharson