Bug#403426: kernel corrupts LUKS partition header on arm

[Clemens Fruhwirth <clemens@endorphin.org>]

At Wed, 20 Dec 2006 17:15:29 +0100,
Martin Michlmayr <tbm@cyrius.com> wrote:

> We're seeing corruption of LUKS partition headers on ARM.  I've
> confirmed this on two different ARM platforms (IXP4xx and IOP32x) and
> with 2.6.17 and 2.6.18.
> 
> Basically, when you create a LUKS partition on a PC and then connect
> it to an ARM box and open it, you get an "automatic header conversion
> from 0.99 to 0.991 triggered" message and afterwards the LUKS
> partition header is corrupted.

Please try the version from subversion
http://luks.endorphin.org/svn/cryptsetup 

I just kicked this conversion routine as it is for pre-1.0 releases
and guess there is no single deployment that will ever need it.

This won't change the bug itself, but it won't corrupt your partition
anymore. It just fails. 

> > Its done something like overwrite the second sector of the header with
> > the first one. I had a look at the cryptsetup code, and the conversion
> > message is triggered by it finding the wrong state code for the
> > passphrase slot - so the data has been overwritten by the time its got
> > there.

That looks right.

A good amount of staring out of the window, drew my attention to 
(read|write|write_lseek)_blockwise in util.c.

Reading from a file description opened with O_DIRECT requires
blockwise reading into an aligned memory segments. That's the reason
for all the magic in these routines.

Looking at read_blockwise, r=read(fd,buf,size) might just return a
short read, that is r<size. But the read_blockwise routine never
covers that case. For some reason arm might behave different than
other archs here.

I just added the r!=bsize case to error checking and an error message
as well.
	while(count) {
		r = read(fd,padbuf,bsize);
		if(r < 0 || r != bsize) {
			fprintf(stderr, "read failed in read_blockwise.\n");
			goto out;
		}
		step = count<bsize?count:bsize;
		memcpy(buf,padbuf,step);
		buf += step;
		count -= step;
	}

The changes are also in subversion.

Please try.
-- 
Fruhwirth Clemens - http://clemens.endorphin.org 
for robots: sp4mtrap@endorphin.org