4

I don't understand ow DM-Verity works.

Reading from here or here I have several doubts about it:

  1. Considering a whole block partition protected by dm-verity: it should verify the data to the hash table up to root hash when accessing it. Does dm-verity verify only the interested data blocks or the whole partition? In the first case, if i need to verify after some time another block in dm-verity protected partition, is the whole procedure performed again?
  2. I have a dm-verity protected blck partition mounted as /dev/sda1. When I see a /dev/sda1 on linux, does it mean that the whole partition has been verified?
  3. Could you explain me what /dev/dm* are and why are they needed?

2 Answers 2

2

Disclaimer: I'm no expert but sharing what I've learned as I set up dm-verity on a RPi. I'll try to address questions 1 and 2.

  1. Considering the explanations of dm-verity that I have found that actually describe the algorithm, including the one in this answer, they explain away the actual algorithm by referring to Merkle Trees. This latter reference has a useful example:

enter image description here

For example, in the picture, the integrity of data block L2 can be verified immediately if the tree already contains hash 0-0 and hash 1 by hashing the data block and iteratively combining the result with hash 0-0 and then hash 1 and finally comparing the result with the top hash. Similarly, the integrity of data block L3 can be verified if the tree already has hash 1-1 and hash 0.

When setting up dm-verity, you will create a hash tree and store it on a separate partition. The system can then verify the block being read by

  • calculating the hash of the block being read
  • combine this calculated hash with the saved hash of the other block to compute the upper level hash.
  • combine this upper level hash with the saved hash at the same level to compute the next upper level hash.
  • repeat until the root hash has been calculated
  • compare the calculated root hash with the saved root hash

You would need to update the stored hash tree each time you write any block to continue to be able to detect tampering.

  1. I suppose it's implementation-dependent. But the implementation in the cryptsetup-bin Debian package and as explained in the first part of this reference checks the entire hash on boot. (The Wikipedia link above also explains that computing the hash tree starting with hashes of blocks is faster than the computing a single is more efficient than computing the hash of the whole data set -- I'm still trying to figure that part out). As I understand it, you can also configure it to verify a block on each read (see this reference).
0
  1. Here's a diagram how it works: https://source.android.com/security/verifiedboot/dm-verity

  2. Most likely yes.

  3. /dev/dm* devices pertain to the device mapper. Speaking of dm-verity, this might be helpful: https://en.wikipedia.org/wiki/Device_mapper https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html

6
  • 1. The first link says Instead, dm-verity verifies blocks individually and only when each one is accessed. When read into memory, the block is hashed in parallel. The hash is then verified up the tree. And since reading the block is such an expensive operation, the latency introduced by this block-level verification is comparatively nominal. . Hence a block of a block device is verified only in case of its access, right?
    – Vilos
    Commented Jul 19, 2020 at 10:51
  • 2. Sorry for the silly question: why? If what I've wrote on 1. is correct, /dev/sda1 is mounted but not yet verified: each block will be verified only if an application will require access to its data, right?
    – Vilos
    Commented Jul 19, 2020 at 10:53
  • 3. /dev/dm* is the device in charge of verify a block of a block device when an access is requested, right?
    – Vilos
    Commented Jul 19, 2020 at 10:55
  • 4. reading on internet, I see that the hash tree is usually loaded into memory by bootloader: why? Why this operation is not perfomed by linux kernel?
    – Vilos
    Commented Jul 19, 2020 at 10:58
  • @Vilos because the bootloader passes this root-hash to the kernel as a command-line parameter so that the kernel can mount the rootfs using dm-verity. The bootloader is signed and trusted in a setup with dm-verity.
    – Étienne
    Commented Nov 22, 2022 at 20:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .