search

eternaltyro / cryptsetup

Since Google code is shuttering...
http://code.google.com/p/cryptsetup
GNU General Public License v2.0
0 stars 0 forks source link

Unknown crypt device type VERITY over Ubuntu 12.04 #181

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
HI,

I have build cryptsetup over Ubuntu 12.04 using standard way with almost all 
the dependent packages compiled manually. Below is the list of all the packages 
which generated dependency errors:-

1) util-linux-ng-2.18.tar.bz2 -->{./configure && make && make install}
2) libgpg-error-1.9.tar.gz --> {./configure && make && make install}
3) libgcrypt-1.5.3.tar.gz --> {./configure && make && make install}
4) LVM2.2.02.99.tgz --> {./configure && make && make install}
5) cryptsetup-1.6.2.tar.bz2 --> {./configure && make && make install}

After that I have changed the running kernel 3.8.x with the debian packages of 
Linux kernel 3.11.x which already have dm-verity.ko module.

6) Then I have insert dm-verity module (modprobe dm-verity)

In order to test verity framework, I have created two sample block devices;one 
for data device and other for hash device:-

7) losetup system.img.raw /dev/loop2
   echo "0 $(blockdev --getsize /dev/loop2) linear /dev/loop2 0" |\ 
   dmsetup  create my_dm

8) dd if=/dev/zero of=/tmp/store1 bs=1024 seek=2047 count=1
   losetup /tmp/store1 /dev/loop0
   echo "0 $(blockdev --getsize /dev/loop0) linear /dev/loop0 0" |\ 
   dmsetup  create my_hash_dm

And finally during test; the veritysetup shows following error instead of Root 
Hash

veritysetup format /dev/mapper/my_dm /dev/mapper/my_hash_dm 

Unknown crypt device type VERITY requested.

I am unable to locate the issue and tried alot. Please indicate if any of the 
step is incorrect and should not be done. Also specify any alternatives.

Thanks
Akash

Original issue reported on code.google.com by actionon...@gmail.com on 25 Nov 2013 at 10:13

GoogleCodeExporter commented 9 years ago 
Can you attach output of the last command with --debug added and also strace 
log of the last command? thanks.

Btw you do not need to use loop devices, veritysetup should allocate them 
automatically if image in file is specified.

Original comment by gmazyl...@gmail.com on 26 Nov 2013 at 12:26

GoogleCodeExporter commented 9 years ago 
Hi,

Thanks for reply; I got the issue! The mistake comes from libgcrypt; it was 
default Ubuntu library that veritysetup was picking (from /lib). So I exported 
LD_LIBRARY_PATH to /usr/lib and all went well!

However I do not understand the behavior of veritysetup. Again here are my 
further steps:-

1) I made the root hash using veritysetup format

   veritysetup format /dev/mapper/my_dm /dev/mapper/my_hash_dm 

   and got the root hash as 66a1b3845......d1c

2) Then I create DM mapping with veritysetup 

   veritysetup create akash_vr /dev/mapper/my_dm /dev/mapper/my_hash_dm  6a1b3845......d1c

3) Next I see the status 

   veritysetup status akash_vr

   /dev/mapper/akash_vr is active.
   type:        VERITY
   status:      verified
   hash type:   1
   data block:  4096
   hash block:  4096
   hash name:   sha256
   salt:        6a28ae9f2492a7e148e6787a39a99ce5bff931bacd2b9d73209b4eb9eaa7731a
   data device: /dev/mapper/my_dm
   size:        1433600 sectors
   mode:        readonly
   hash device: /dev/mapper/my_hash_dm1
   hash offset: 8 sectors

4) BUT when I do the Verification part it shows "VERIFICATION FAILED". I do not 
understand the contradictory part.

   veritysetup verify /dev/mapper/my_dm /dev/mapper/my_hash_dm 66a1b3845......d1c

   Verification failed at position 2125824.
   Verification of data area failed.

 Is this is the expected output ???

 Thanks
 Akash

Original comment by actionon...@gmail.com on 26 Nov 2013 at 1:21

GoogleCodeExporter commented 9 years ago 
Well, it means there is a data corruption :) Probably problem elsewhere.

I would try to remove some levels of indirection and retry 
(format->create->verify, run it directly over images: veritysetup format 
<file_img1> <file_img2> ...)

If ti still doesn't work, check and paste here output of lsblk and output of 
veritysetup commands with added --debug.

Original comment by gmazyl...@gmail.com on 26 Nov 2013 at 1:47

GoogleCodeExporter commented 9 years ago 
Hi,

Moving further to progressive path :) I have done what you suggested. The steps 
are as follows:-

1) First format with the two images:-

   veritysetup format /media/sf_Downloads/images/ /tmp/store1
   Got roothash of 087a6ad153cf858f451ec1373958e4772d348304837dab26a2829acaa10aebab

2) Create a mapping :-

   veritysetup create --debug akash_vr /media/sf_Downloads/images/ /tmp/store1 087a6ad153cf858f451ec1373958e4772d348304837dab26a2829acaa10aebab
   # Running command create.
    # Allocating crypt device /tmp/store1 context.
    # Trying to open and read device /tmp/store1.
    # Initialising device-mapper backend library.
    # Trying to load VERITY crypt type from device /tmp/store1.
    # Crypto backend (gcrypt 1.5.0) initialized.
    # Reading VERITY header of size 512 on device /tmp/store1, offset 0.
    # Setting ciphertext data device to /media/sf_Downloads/images/system.img.raw.
    # Trying to open and read device /media/sf_Downloads/images/system.img.raw.
    # Activating volume akash_vr by volume key.
    # Detected kernel Linux 3.11.0-031100-generic i686.
    # dm version   OF   [16384] (*1)
    # dm versions   OF   [16384] (*1)
    # Detected dm-verity version 1.2.0.
    # Device-mapper backend running with UDEV support disabled.
    # dm status akash_vr  OF   [16384] (*1)
    # Trying to activate VERITY device akash_vr using hash sha256.
    # Allocating a free loop device.
    # Trying to open and read device /dev/loop3.
    # Allocating a free loop device.
    # Trying to open and read device /dev/loop5.
    # Calculated device size is 1433600 sectors (RW), offset 0.
    # Detected kernel Linux 3.11.0-031100-generic i686.
    # dm versions   OF   [16384] (*1)
    # Detected dm-verity version 1.2.0.
    # Device-mapper backend running with UDEV support disabled.
    # DM-UUID is CRYPT-VERITY-9b603a109ec4491dabd271fb9b305cb2-akash_vr
    # Detected kernel Linux 3.11.0-031100-generic i686.
    # dm versions   OF   [16384] (*1)
    # Detected dm-verity version 1.2.0.
    # Device-mapper backend running with UDEV support disabled.
    # dm create akash_vr CRYPT-VERITY-9b603a109ec4491dabd271fb9b305cb2-akash_vr OF   [16384] (*1)
    # dm reload akash_vr  OFR   [16384] (*1)
    # dm resume akash_vr  OFR   [16384] (*1)
    # akash_vr: Stacking NODE_ADD (252,0) 0:0 0600
    # akash_vr: Stacking NODE_READ_AHEAD 256 (flags=1)
    # akash_vr: Processing NODE_ADD (252,0) 0:0 0600
    # Created /dev/mapper/akash_vr
    # akash_vr: Processing NODE_READ_AHEAD 256 (flags=1)
    # akash_vr (252:0): read ahead is 256
    # akash_vr: retaining kernel read ahead of 256 (requested 256)
    # Detected kernel Linux 3.11.0-031100-generic i686.
    # dm versions   OF   [16384] (*1)
    # Detected dm-verity version 1.2.0.
    # Device-mapper backend running with UDEV support disabled.
    # dm status akash_vr  OF   [16384] (*1)
    # Verity volume akash_vr status is V.
    # Releasing crypt device /tmp/store1 context.
    # Releasing device-mapper backend.
    # Closed loop /dev/loop5 (/media/sf_Downloads/images/system.img.raw).
    # Closed loop /dev/loop3 (/tmp/store1).
    Command successful.

3) And then perform the verify (WHICH WENT SUCCESSFUL!)

   veritysetup verify --debug akash_vr /media/sf_Downloads/images/ /tmp/store1 087a6ad153cf858f451ec1373958e4772d348304837dab26a2829acaa10aebab

    # cryptsetup 1.6.2 processing "veritysetup verify --debug /media/sf_Downloads/images/system.img.raw /tmp/store1 087a6ad153cf858f451ec1373958e4772d348304837dab26a2829acaa10aebab"
    # Running command verify.
    # Allocating crypt device /tmp/store1 context.
    # Trying to open and read device /tmp/store1.
    # Initialising device-mapper backend library.
    # Trying to load VERITY crypt type from device /tmp/store1.
    # Crypto backend (gcrypt 1.5.0) initialized.
    # Reading VERITY header of size 512 on device /tmp/store1, offset 0.
    # Setting ciphertext data device to /media/sf_Downloads/images/system.img.raw.
    # Trying to open and read device /media/sf_Downloads/images/system.img.raw.
    # Activating volume [none] by volume key.
    # Trying to activate VERITY device [none] using hash sha256.
    # Verification of data in userspace required.
    # Hash verification sha256, data device /media/sf_Downloads/images/system.img.raw, data blocks 179200, hash_device /tmp/store1, offset 1.
    # Using 3 hash levels.
    # Data device size required: 734003200 bytes.
    # Hash device size required: 5787648 bytes.
    # Verification of data area succeeded.
    # Verification of root hash succeeded.
    # Releasing crypt device /tmp/store1 context.
    # Releasing device-mapper backend.
    Command successful.

4) However "STATUS" command of veritysetup now shows contradiction with 
"CORRUPTED" status. Again contradictory behavior.

   veritysetup status akash_vr

    # cryptsetup 1.6.2 processing "veritysetup --debug status akash_vr"
    # Running command status.
    # Initialising device-mapper backend library.
    # Detected kernel Linux 3.11.0-031100-generic i686.
    # dm version   OF   [16384] (*1)
    # dm versions   OF   [16384] (*1)
    # Detected dm-verity version 1.2.0.
    # Device-mapper backend running with UDEV support disabled.
    # dm status akash_vr  OF   [16384] (*1)
    # Releasing device-mapper backend.
    /dev/mapper/akash_vr is active.
    # Allocating crypt device context by device akash_vr.
    # Initialising device-mapper backend library.
    # Detected kernel Linux 3.11.0-031100-generic i686.
    # dm versions   OF   [16384] (*1)
    # Detected dm-verity version 1.2.0.
    # Device-mapper backend running with UDEV support disabled.
    # dm status akash_vr  OF   [16384] (*1)
    # Releasing device-mapper backend.
    # Detected kernel Linux 3.11.0-031100-generic i686.
    # Detected dm-verity version 1.2.0.
    # Device-mapper backend running with UDEV support disabled.
    # Detected kernel Linux 3.11.0-031100-generic i686.
    # Detected dm-verity version 1.2.0.
    # Device-mapper backend running with UDEV support disabled.
    # Trying to open and read device /dev/loop5.
    # Verity volume akash_vr status is C.
    # Allocating crypt device /dev/loop5 context.
    # Trying to open and read device /dev/loop5.
    # Initialising device-mapper backend library.
    # Detected kernel Linux 3.11.0-031100-generic i686.
    # dm versions   OF   [16384] (*1)
    # Detected dm-verity version 1.2.0.
    # Device-mapper backend running with UDEV support disabled.
    # Detected kernel Linux 3.11.0-031100-generic i686.
    # dm versions   OF   [16384] (*1)
    # Detected dm-verity version 1.2.0.
    # Device-mapper backend running with UDEV support disabled.
    # dm table akash_vr  OF   [16384] (*1)
    # Trying to open and read device /dev/loop5.
    # Trying to open and read device /dev/loop3.
    # dm status akash_vr  OF   [16384] (*1)
    # Verity volume akash_vr status is C.
      type:        VERITY
    # Detected kernel Linux 3.11.0-031100-generic i686.
    # dm versions   OF   [16384] (*1)
    # Detected dm-verity version 1.2.0.
    # Device-mapper backend running with UDEV support disabled.
    # Detected kernel Linux 3.11.0-031100-generic i686.
    # dm versions   OF   [16384] (*1)
    # Detected dm-verity version 1.2.0.
    # Device-mapper backend running with UDEV support disabled.
    # dm table akash_vr  OF   [16384] (*1)
    # dm status akash_vr  OF   [16384] (*1)
    # Verity volume akash_vr status is C.
      status:      corrupted
      hash type:   1
      data block:  4096
      hash block:  4096
      hash name:   sha256
      salt:        c9d9b443ae6ea9fa24f9ccd134907f9da2a8294db2aadf626675df86162feb8f
      data device: /dev/loop5
      data loop:   /media/sf_Downloads/images/system.img.raw
      size:        1433600 sectors
      mode:        readonly
      hash device: /dev/loop3
      hash loop:   /tmp/store1
      hash offset: 8 sectors
    # Releasing crypt device /dev/loop3 context.
    # Releasing device-mapper backend.
    Command successful.

    OUTPUT of lsblk:-
    NAME              MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
    sda                 8:0    0    20G  0 disk  
    ├─sda1              8:1    0  19.5G  0 part  /
    ├─sda2              8:2    0     1K  0 part  
    └─sda5              8:5    0   510M  0 part  [SWAP]
    sr0                11:0    1  61.2M  0 rom   /media/VBOXADDITIONS_4.3.2_90405
    loop0               7:0    0     2M  0 loop  
    loop1               7:1    0   700M  0 loop  
    loop2               7:2    0   700M  0 loop  
    loop3               7:3    0   5.5M  0 loop  
    └─akash_vr (dm-0) 252:0    0   700M  1 crypt 
    loop4               7:4    0   5.9M  0 loop  
    loop5               7:5    0   700M  0 loop  
    └─akash_vr (dm-0) 252:0    0   700M  1 crypt

Original comment by actionon...@gmail.com on 27 Nov 2013 at 12:10

GoogleCodeExporter commented 9 years ago 
Why is there so many used loop devices (what is loop0,1,2,4)? It seems to me 
that there is still some forgotten loop mapping to your image...

Can you please check it (losetup) detach all old loop devices and repeat the 
test?

Original comment by gmazyl...@gmail.com on 30 Nov 2013 at 9:18

GoogleCodeExporter commented 9 years ago 
I have removed all the loops (via rebooting Ubuntu since veritysetup remove was 
not working for akash_vr device). After that performing all the steps, 
successfully gives the results expected. :)

One more query is about the behavior of mount; I mount the system.img.raw as an 
ext4 partition in RW mode and then just umount it without doing any changes. 

Then, if I perform veritysetup verify over that it got fails right at Sector 0. 
Is this behavior is expected ? By this,are we considering the fact that the 
image ALWAYS be mounted in Read Only Mode?

Thanks alot!!

Original comment by actionon...@gmail.com on 2 Dec 2013 at 8:09

GoogleCodeExporter commented 9 years ago 
Yes, it is expected. Mounting filesystem read/write means at least write to the 
superblock (time of last mount and similar info) but probably also some 
operations to to fs log etc. (Even if there is no other activity on device.) So 
always mount device with read-only if used over verity.

Original comment by gmazyl...@gmail.com on 2 Dec 2013 at 7:58

GoogleCodeExporter commented 9 years ago 
Hi,

I required one more answer from your side. I have performed Root hashing on 
system.img (of my Galaxy S2) both on the Mobile and Ubuntu, however the Root 
Hash is different in case. I have used same salt and uuid as per Galaxy S2. Is 
the behaviour expected? Steps are:-

1) On Galaxy S2
            ./veritysetup.static format /dev/block/platform/sdhci.1/by-name/system /data/hash_store
            VERITY header information for /data/hash_store
            UUID:                   a329429b-c590-4a73-8cae-745529e4c6d2
            Hash type:              1
            Data blocks:            179200
            Data block size:        4096
            Hash block size:        4096
            Hash algorithm:         sha256
            Salt:                   4a145c2dbcc269211eba1e7172f1c6770c242cadb697ae2573c62737bc4d2c02
            Root hash:              877b0848149e92487bce91a9ecdf76466fdaeee82717a74f09d4844994e84850

2) And on my Ubuntu Machine:-

   i)   ./simg2img system.img system.img.raw
   ii)  mount -t ext4 -r system.img.raw /mnt

   iii) veritysetup format /dev/loop0 /tmp/hash_device --salt 4a145c2dbcc269211eba1e7172f1c6770c242cadb697ae2573c62737bc4d2c02 --uuid=a329429b-c590-4a73-8cae-745529e4c6d2

            VERITY header information for /tmp/hash_device
            UUID:               a329429b-c590-4a73-8cae-745529e4c6d2
            Hash type:          1
            Data blocks:        179200
            Data block size:    4096
            Hash block size:    4096
            Hash algorithm:     sha256
            Salt:               4a145c2dbcc269211eba1e7172f1c6770c242cadb697ae2573c62737bc4d2c02
            Root hash:          9aaffbe305e77c69f30a5f42d1eb02c5fe4daf129e8ea719161d2c07222305ab
            # Releasing crypt device /tmp/hash_device context.
            # Releasing device-mapper backend.

Original comment by actionon...@gmail.com on 4 Dec 2013 at 8:47

GoogleCodeExporter commented 9 years ago 
I am unable to link the libgcrypt at /usr/local/lib/libgcrypt.so

I did 
   1) export LD_LIBRARY_PATH=/usr/local/lib/
   2) make
   3) make install
   4) veritysetup format /dev/mapper/my_ro /dev/mapper/my_hash --debug 

Below is the result:

# cryptsetup 1.6.3 processing "veritysetup format /dev/mapper/my_ro 
/dev/mapper/my_hash --debug"
# Running command format.
# Allocating crypt device /dev/mapper/my_hash context.
# Trying to open and read device /dev/mapper/my_hash.
# Initialising device-mapper backend, UDEV is enabled.
# Formatting device /dev/mapper/my_hash as type VERITY.
# Crypto backend (gcrypt 1.5.0) initialized.
Unknown crypt device type VERITY requested.
# Releasing crypt device /dev/mapper/my_hash context.
# Releasing device-mapper backend.
Command failed with code 22: Unknown crypt device type VERITY requested.

When I did ldd /usr/sbin/veritysetup
    linux-vdso.so.1 =>  (0x00007fffe35fe000)
    libcryptsetup.so.4 => /lib/libcryptsetup.so.4 (0x00007f8b80dc9000)
    libpopt.so.0 => /lib/x86_64-linux-gnu/libpopt.so.0 (0x00007f8b80bbd000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8b807f3000)
    libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f8b805ee000)
    libdevmapper.so.1.02.1 => /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1 (0x00007f8b803b7000)
    libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007f8b80138000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f8b81000000)
    libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f8b7ff19000)
    libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f8b7fd08000)
    libgpg-error.so.0 => /usr/local/lib/libgpg-error.so.0 (0x00007f8b7fb02000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8b7f8fe000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8b7f6f6000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8b7f4d8000)

Any idea about how to solve this?

Original comment by rraj...@gmail.com on 11 Jan 2014 at 10:45

GoogleCodeExporter commented 9 years ago 
Compile all the dependent library manually with a certain --prefix path in 
"config" script.I think all the libraries are taken from Ubuntu default path. 
After compilation update the LD_LIBRARY_PATH.

For example: 
./config --prefix=/tmp/my_libs
export LD_LIBRARY_PATH=/tmp/my_libs

It should work

Original comment by actionon...@gmail.com on 21 Jan 2014 at 12:46