On 07/14/2016 07:19 PM, Gyula Kovács wrote: > Dear All, > > I'm trying to bring up and running a small read only partition with > using of dm-verity. > A short description of my platform: > - CPU core: ARM Cortex A7 > - Kernel version: 3.10.49 > - The CONFIG_DM_VERITY is set to "y" in kernel configuration. > - The read only partition is a squashfs on ubiblock. The ubiblock was > back-ported from kernel 3.15. > - The verity_key file was not created in the boot directory. > I followed this description: > https://nelenkov.blogspot.hu/2014/05/using-kitkat-verified-boot.html?view=classic > I could finish the setup procedure successfully. > > I tried two usage scenarios: > > 1. Creating a mapping device on target > I executed the following commands: > - veritysetup --hash-offset=HASH_OFFSET create vrty /dev/ubiblock0_9 > /dev/ubiblock0_9 GOOD_ROOT_DIGEST > - mount -t squashfs -o ro /dev/mapper/vrty /sbro/ > I could read the partition as expected. > I repeated the test above with a corrupt partition image (one byte was > changed in the data area.) > I couldn't read the partition, as it was expected. > I did a test with bad digest: > - veritysetup --hash-offset=HASH_OFFSET create vrty /dev/ubiblock0_9 > /dev/ubiblock0_9 BAD_ROOT_DIGEST > - mount -t squashfs -o ro /dev/mapper/vrty /sbro/ > I couldn't read the partition, as it was expected. > Summarized, the dm-verity was working as expected. > > 2. I tried to mount the block device according to description on > https://nelenkov.blogspot.hu/2014/05/using-kitkat-verified-boot.html?view=classic > page. > I added the following line to fstab file: > /dev/ubiblock0_9 /sbro squashfs ro,wait,verify I would say that you are accessing your block device directly here, without dm-verity as underlying device. If there is lsblk, check it with it. (Or dmsetup ls --tree) You should see dm-verity in between if properly configured. You should be also able to see data "verified" status using veritysetup status <device> (vrty in your case). I have no idea how is the fstab (and verity flag) processed on Android. There are even some shortcommings in the description you linked (like /dev/block/dm-0 is not safe, this is dynamically allocated so it is "some device that was created as a the first device through device-mapper"). > I created the ubiblock device with the "ubiblock -c /dev/ubi0_9" command. > After executing the "mount -a" command I could read the content of /sbro > directory. > But according to the description, without the verity_key file the > partition shouldn't be read. > I repeated my test with a corrupt partition image, and I could read it. You can always read device directly - the hash integrity tree is just appended to your image, if there is not dm-verity in between configured, this hash tree is just not used... > Summarized: > The dm-verity is working fine when I'm mounting a mapping device, but it > is not working (allows reading of partition always) when I'm mounting a > block device. Because you have to setup dm-verity on top of the block device and use the new virtual verity device instead. (Perhaps it should do "verify" flag in fstab automatically but it would be better to ask in some Android developers list why it is not working here.) Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
