use veritysetup to test filesystem (romfs, squashfs and ext2), the romfs is failed

[GoogleCodeExporter]

What steps will reproduce the problem?
1.dd if=romfs.img of=/dev/mtdblock5 bs=1024 count=10240
4097+0 records in
4097+0 records out
4195328 bytes (4.0MB) copied, 1.686202 seconds, 2.4MB/s

2.mount -t romfs /dev/mtdblock5 /tmp/

3.ls /tmp/
blkone  blktwo

4.hexdump /tmp/blkone
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0200000

5.hexdump /tmp/blktwo
0000000 6161 6161 6161 6161 6161 6161 6161 6161
*
0200000

6.umount /tmp

7.veritysetup format /dev/mtdblock5 /dev/mtdblock6
VERITY header information for /dev/mtdblock6
UUID:                   5f1872a8-6bd0-4824-82fc-886b944b60c2
Hash type:              1
Data blocks:            12800
Data block size:        4096
Hash block size:        4096
Hash algorithm:         sha256
Salt:                   
73be30a3f4338cd9046492b9abcb172bb6fe4b741e9104cc7cf768dbd0901547
Root hash:              
408323fad51d3a85c26384270da3980a63874b67d1e30a47330bd163bba98a41

8.veritysetup create dm-romfs /dev/mtdblock5 /dev/mtdblock6 408323fad51d3a85c263
84270da3980a63874b67d1e30a47330bd163bba98a41

9.mount -t romfs /dev/mapper/dm-romfs /tmp/

10.ls /tmp
ls: /tmp/ No such file or directory
blkone

11.cd /tmp

12.ls
ls: ./ No such file or directory
blkone

13.hexdump blkone
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0080000 0000 0200 0000 0000 2000 0000 0426 8a94
0080010 6c62 746b 6f77 0000 0000 0000 0000 0000
0080020 6161 6161 6161 6161 6161 6161 6161 6161
*
0100020 0000 0000 0000 0000 0000 0000 0000 0000
*
0100380 ffff ffff ffff ffff ffff ffff ffff ffff
*
0200000

What is the expected output? What do you see instead?
When mtdblock5 is used to verity format and create, the data is changed.

What version of the product are you using? On what operating system?
veritysetup 1.6.2
Linux 192.168.6.108 3.4.67_s40 #13 SMP Sun Jan 26 23:19:11 CST 2014 armv7l 
GNU/Linux

Please provide any additional information below.
If the squashfs and ext2 filesystem is Accorded to this to do, it is succeed.

Original issue reported on code.google.com by askxia...@gmail.com on 26 Jan 2014 at 8:27

[GoogleCodeExporter]

Again, this looks like kernel problem. Can you test more recent kernel here?

Also please always add debug output of veritysetup command (add --debug).

Not sure if I can reproduce it, but I think this should be reported to 
dm-devel@redhat.com (it looks like veritysetup properly configures dm-verity 
kernel module here.)

Original comment by gmazyl...@gmail.com on 26 Jan 2014 at 9:08

[GoogleCodeExporter]

# veritysetup --debug format /dev/mtdblock5 /dev/mtdblock6 
# cryptsetup 1.6.2 processing "veritysetup --debug format /dev/mtdblock5 
/dev/mtdblock6"
# Running command format.
# Allocating crypt device /dev/mtdblock6 context.
# Trying to open and read device /dev/mtdblock6.
# Initialising device-mapper backend library.
# Formatting device /dev/mtdblock6 as type VERITY.
# Crypto backend (gcrypt 1.5.3) initialized.
# Setting ciphertext data device to /dev/mtdblock5.
# Trying to open and read device /dev/mtdblock5.
# Hash creation sha256, data device /dev/mtdblock5, data blocks 12800, 
hash_device /dev/mtdblock6, offset 1.
# Using 2 hash levels.
# Data device size required: 52428800 bytes.
# Hash device size required: 417792 bytes.
# Updating VERITY header of size 512 on device /dev/mtdblock6, offset 0.
VERITY header information for /dev/mtdblock6
UUID:                   0c815957-0e03-4497-80fb-666df9b1ea30
Hash type:              1
Data blocks:            12800
Data block size:        4096
Hash block size:        4096
Hash algorithm:         sha256
Salt:                   
2bba53d029240fe3d5d8806f60236d55debb59f310cdafadf00496a51b854479
Root hash:              
f56752b95561166a12b300e6a59f77a8dc9a15b0d4d703cf1e47672313938322
# Releasing crypt device /dev/mtdblock6 context.
# Releasing device-mapper backend.
Command successful.

# veritysetup --debug create dm-romfs /dev/mtdblock5 /dev/mtdblock6 f56752b95561
166a12b300e6a59f77a8dc9a15b0d4d703cf1e47672313938322
# cryptsetup 1.6.2 processing "veritysetup --debug create dm-romfs 
/dev/mtdblock5 /dev/mtdblock6 
f56752b95561166a12b300e6a59f77a8dc9a15b0d4d703cf1e47672313938322"
# Running command create.
# Allocating crypt device /dev/mtdblock6 context.
# Trying to open and read device /dev/mtdblock6.
# Initialising device-mapper backend library.
# Trying to load VERITY crypt type from device /dev/mtdblock6.
# Crypto backend (gcrypt 1.5.3) initialized.
# Reading VERITY header of size 512 on device /dev/mtdblock6, offset 0.
# Setting ciphertext data device to /dev/mtdblock5.
# Trying to open and read device /dev/mtdblock5.
# Activating volume dm-romfs by volume key.
# Detected kernel Linux 3.4.67_s40 armv7l.
# dm version   OF   [16384] (*1)
# dm versions   OF   [16384] (*1)
# Detected dm-verity version 1.0.0.
# Detected dm-crypt version 1.11.0, dm-ioctl version 4.22.0.
# Device-mapper backend running with UDEV support disabled.
# dm status dm-romfs  OF   [16384] (*1)
# Trying to activate VERITY device dm-romfs using hash sha256.
# Calculated device size is 102400 sectors (RW), offset 0.
# DM-UUID is CRYPT-VERITY-0c8159570e03449780fb666df9b1ea30-dm-romfs
# dm create dm-romfs CRYPT-VERITY-0c8159570e03449780fb666df9b1ea30-dm-romfs OF  
 [16384] (*1)
# dm reload dm-romfs  OFRW    [16384] (*1)
# dm resume dm-romfs  OFRW    [16384] (*1)
# dm-romfs: Stacking NODE_ADD (252,0) 0:0 0600
# dm-romfs: Stacking NODE_READ_AHEAD 256 (flags=1)
# dm-romfs: Processing NODE_ADD (252,0) 0:0 0600
# dm-romfs: Processing NODE_READ_AHEAD 256 (flags=1)
# dm-romfs (252:0): read ahead is 256
# dm-romfs: retaining kernel read ahead of 256 (requested 256)
# dm status dm-romfs  OF   [16384] (*1)
# Verity volume dm-romfs status is V.
# Releasing crypt device /dev/mtdblock6 context.
# Releasing device-mapper backend.
Command successful.

Original comment by askxia...@gmail.com on 26 Jan 2014 at 9:34

[GoogleCodeExporter]

The romfs is succeed to dmsetup. The process of operation is：
# dmsetup create test-romfs --table "0 2048000 81920 /dev/mtdblock6 0" 
device-mapper: table: 252:0: 81920: unknown target type
device-mapper: ioctl: error adding target to table
device-mapper: reload ioctl on test-romfs failed: Invalid argument
Command failed

# dmsetup create test-romfs --table "0 81920 linear /dev/mtdblock6 0"

# mount /dev/mapper/test-romfs tmp/

# cd tmp/

# ls
blkone  blktwo

# hexdump blkone 
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0200000

# hexdump blkone 
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0200000

Original comment by askxia...@gmail.com on 26 Jan 2014 at 9:56

[GoogleCodeExporter]

# Verity volume dm-romfs status is V.

Ok, so veritysetup works properly (dm-verity reports verified status). So it is 
kernel problem.

Original comment by gmazyl...@gmail.com on 26 Jan 2014 at 10:02

[GoogleCodeExporter]

I has use the kernel3.0 to test, and the dm-verity drive has been transplanted 
into kernel3.0. I test these on nand flash and U-disk on kernel3.0. The result 
is same.
The squashfs and ext2 filesystem is succeed on nand flash and U-disk, the romfs 
is failed.

Original comment by askxia...@gmail.com on 26 Jan 2014 at 10:05

[GoogleCodeExporter]

I tried romfs in kernel 3.13 (with normal sata disk partitions) and it works 
with veritysetup.

Can you try use e.g. loopback to check that the problem is in MTD device 
mapping? IOW create both data and verity hash as file images and mount them 
directly using veritysetup (no mtd device in stack).

Original comment by gmazyl...@gmail.com on 26 Jan 2014 at 11:01

[GoogleCodeExporter]

Can you try use e.g. loopback to check that the problem is in MTD device 
mapping? IOW create both data and verity hash as file images and mount them 
directly using veritysetup (no mtd device in stack).

I don't know，how to use e.g. loopback to check, how to mount them directly 
using veritysetup

Original comment by askxia...@gmail.com on 27 Jan 2014 at 3:06