dm-verity and backing_dev_info

David Legault legault.david at gmail.com
Thu Nov 20 10:56:17 EST 2014


Hello,

I'm working on a project where I use the dm-verity data mapper on top of a
regular emmc device block. The intent is that once the verity device mapper
is verified successfully (top level hash verification) on top of the emmc
block device and mounted to a filesystem (ext4) that the filesystem is
trusted in some way and store that bit of information somewhere in kernel
space. My original thought was to think that the new dm-verity block device
would of had it's own backing_dev_info structure on which I would of added
a new capability called BDI_CAP_TRUSTED which then could of been used for
additional checks to see if files come from a trusted file system. I
instrumented the kernel exec command to verify if the backing_dev_info was
different depending on if a file same from a dm-verity mounted filesystem
compared to another filesystem which is not dm-verity (both are on the same
emmc block device). After executing I realized after that inspecting the
backing_dev_info of each file coming from these 2 different locations point
to the same 'block' backing_dev_info structure so this obviously wouldn't
work out of the box as easily.

Can one replace the backing_dev_info structure of a dm-verity block device
with a custom one so I could add a 'trusted' flag to its capabilities? Then
any file coming from that block device would allow me to verify the
capabilities (in the kernel exec command for example).

If that can't be done, is there any other avenue in the kernel where this
sort of flag could be added and verified on a file?

Hacking aorund in the kernel is all pretty new to me so I'm not aware of
all the data structures invloved and how they relate to each other all over
the kernel and its block/fs functionality.

If you know of any level of documentation that explains how it works, that
would also be great to help me digest all of this.

Thanks

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141120/715159a6/attachment.html 


More information about the Kernelnewbies mailing list