Re: Bug#403426: kernel corrupts LUKS partition header on arm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At Tue, 2 Jan 2007 19:04:41 +0100,
Martin Michlmayr <tbm@xxxxxxxxxx> wrote:
> 
> * Clemens Fruhwirth <clemens@xxxxxxxxxxxxx> [2007-01-02 18:00]:
> > Does luksDump report the same things on both architecture?
> 
> Yes.

After a bit of debugging on Gordon's slug, I found out that we have
some kind of read race/read corruption when reading the encrypted
master key from a key slot.

If you get into luks/keyencryption.c:LUKS_decrypt_from_storage and replace
	return LUKS_endec_template(dst,dstLength,hdr,key,keyLength, device, sector, backend, read_blockwise, O_RDONLY);
by something like
        int r=LUKS_endec_template(dst,dstLength,hdr,key,keyLength, device, sector, backend, read_blockwise, O_RDONLY);
        while(dstLength) {
                hexprint(dst, 32);
                dstLength-=32;
                dst+=32;
                printf("\n");
        }
        return r;
you get the whole decrypted content dumped to stdout. Just to give you
a brief idea of how master key decryption from a key slot works:
cryptsetup derives a user key, sets up a temporary dm-crypt mapping
with that user key, and starts to read encrypted content from the
underlying device via the temporary dm-crypt mapping.

The problem: The decrypted content is _different_ for two identical
runs. When you use the debugging sniplet from above you can see, the
corruptions seem to be displaced copies of other content parts. For
instance, when every character below is a 32 byte block then we would
see:

a b c d e f 
a b c d c f

I have no idea why 32 byte block in particular. There seem to be no
regular pattern in the corruption, for instance every x'th block, but
there is a regular pattern in which block is duplicated at the point
of the corruption, namely the previous 16th block. (Notice 16*32byte =
512 byte = sector size. Welcome to linux number mysticism).

As far as I understand page caching comes after dm-crypt, so maybe we
have some kind of cache corruption here?

On more things: The situation stabilizes under strace. Using strace
usually lets you open the LUKS partition.
-- 
Fruhwirth Clemens - http://clemens.endorphin.org 
for robots: sp4mtrap@xxxxxxxxxxxxx

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux