Fwd: LVM/BTRFS on LUKS unreadable

[Klemens Nanni]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

- -------- Forwarded Message --------
Subject: LVM/BTRFS on LUKS unreadable
Date: Mon, 17 Aug 2015 23:24:32 +0000
From: Autoboot <address@hidden>
To: address@hidden

Hello,

GRUB 2.02~beta2 as of commit afd0f21b2027310fda52b00ac1b964041d39a363
used as autoboot payload on a ThinkPad X201 here.

After setting up LVM on LUKS and writing random test files on the disk,
GRUB2 opens the disk but cannot read it's content at (crypto0).

Disk setup:
        $ cryptsetup luksFormat /dev/sdb
        $ cryptsetup open /dev/sdb test
        $ pvcreate /dev/mapper/test
        $ vgcreate test /dev/mapper/test
        $ lvcreate test -L 50G -n root
        $ mkfs.ext4 -L test_root /dev/mapper/test-root
        $ mount /dev/mapper/test-root /mnt
        $ dd if=/dev/urandom bs=1M count=20M of=/mnt/20M

GRUB Shell:
        (all modules incl. lvm properly loaded)
        $ cryptomount (ahci0)
                [...]
                Slot 0 opened

        $ cat (proc)/luks_script
                luks_mount <hexcode> 4096 aes-xts-plain <other hexcode>

        $ ls
                (proc) (memdisk) (cbfsdisk) (crypto0) (ahci0)

        $ ls -l
                [...]
                Device ahci0: No known Filesystem detected
                [...]
                Device crypto0: Filesystem cannot be accessed

        $ debug=cryptodisk

        $ ls (crypto0)
                disk/cryptodisk.c:531: Opening device crypto0
                error: disk `crypto0' not found.


The same happens when replacing LVM with BTRFS, both disk setups can be
mounted but are read fine from userspace, though. I set up the disk on
two different machines to make sure, but with no avail.

Note that this setup does not have any MBR/GPT at all, LUKS and
LVM/BTRFS both use raw device paths since they are capable of completely
replacing partition tables.

I tried manually opening one of my actual installation disks (/boot on
sda1, LVM on LUKS on sda2) the same way, but with no avail. Note that
this disk gets booted every day using the very same X201, so it's
definetely a GRUB2 problem.

Setting up the test disk exactly like shown above but without encryption
(LVM on raw device /dev/sdb) works, I can successfully read
it's content in GRUB

        $ ls
                [...] (lvm/test-root)

        $ ls (test/lvm-root)/
                lost+found 20M

which seems to make it an issue with cryptomount only. To further
verify it's not the test disk being incorrectly read by GRUB, I
"wiped" it by running
        $ cryptsetup luksFormat -c serpent /dev/sdb
        < open LUKS, create LVM/BTRFS, mount, write data >
        < test in GRUB shell >

since writing zeros or random data using
        $ dd if=/dev/(zero|urandom) bs=1M /dev/sdb

to the device results in the same state as encrypting it with another
cipher rendering all old data look random as well (correct me if I'm
wrong). Still the same behaviour.

Has anyone else experiences this before? I don't know what to do, any
help is highly appreciated.


Regards,
Klemens Nanni
(kl3 on IRC)

- -- 
Encrypt your messages using GNUPG if you can - nobody likes snoopers!
For more detailed information, look at the FSF's Email Self-Defense
Guideguide under https://emailselfdefense.fsf.org
Autoboot Key ID: 0xB375A7EE | fingerprint: 6D43 AB28 A92C 9278 E8F8
40A9 0A3A 37D8 B375 A7EE


-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJV3fmrAAoJEAo6N9izdafugTwP/08b+G6P/0k8Jdl3/+cetyEq
RtoIlrvFwuCLnxavBRRot1TfG1bIU5QcPJUbUHJdTwIxOsm03QMgNEIip4MvlyGs
IVW4+AxEmVWIIHKo1rdhCGGs4h+BLXKqTuLXD7qQXiepVxRiNrQoACJjbF8mBV/G
SW0N/PvygR5TPyUOcMOc/B/V7EjVCOmLthgJJsQkrfvFsgIioBPICwM1127LfAd5
uQSrAc2ScBM3Q9xuIeXU0W+k9JFZKUJCaH2cgbwUI9k2mqkkBUtBTpaoW2Gal7fd
ONjNSfFjcnch4AuxLnPRZYIC4tE7ncRNfo0a7EmNNiRxys534N15GqFDLz/JyYH5
SD28iuzgrPYG+Frc7IQySdjnVrT/jjvv+NLgGy41yGQerj6GkjPLTvyTPTKxotk2
ZJ/F85enBXCF26+DSqCa6W8BQrUkhQ99HsTb2+vzN4oHTWZ01344RHdnNt6V58T9
Ls96SCiC4vYy0IfkvXo0pPZYVzL8yexF8Dl8nZXaAZ606yTE0WNuFLgtClxJl1Vj
NvoJrgjT0D4DKqghZ2TeryuFdC4KgQUH13Ov5nKGMwkusCV9OHNychuVHNIeyM+u
gulGr2xacUh+t8790q+hWW3mW3JTltWP/b0W6yIiYEpZBnVFLPw+0GqCa5I2bDOh
wafFDDvuu5TVUkqzKUtM
=CYSH
-----END PGP SIGNATURE-----