A setback for fs-verity

Posted Jan 3, 2019 23:23 UTC (Thu) by ohrn (subscriber, #5509)
Parent article: A setback for fs-verity

Dumb question. What is the purpose of using a hash tree?

Seems to me a single level list of hashes for the data blocks would be enough?

If someone malicious can modify a hash in the list they can surely modify the entire tree, so hashing the hashes doesn't seem to give much of a benefit?

A setback for fs-verity

Posted Jan 3, 2019 23:29 UTC (Thu) by neilbrown (subscriber, #359) [Link]

> If someone malicious can modify a hash in the list they can surely modify the entire tree, so hashing the hashes doesn't seem to give much of a benefit?

A benefit is that you can crypto-sign the root hash.

A setback for fs-verity

Posted Jan 10, 2019 4:51 UTC (Thu) by thestinger (guest, #91827) [Link]

The hashes of the blocks need to be verified too. The information on the disk isn't trusted. The hashes/signatures aren't generated locally but rather are shipped with the updates for those components. The fs-verity code is only used for dynamically updated components outside the base OS partitions, which are verified via a signature (vbmeta), hashes in vbmeta (boot/dtbo) and dm-verity (bootstrapped from vbmeta). Their fs-verity approach lets them extend the verification to components in the userdata partition.