[diegonehab]

Summary

verify_hash_tree compared each page hash with memory and nothing else. A machine could pass it with a corrupted dense inner node, sparse node, padding page, dirty page tree, or page hash-tree cache entry, and get_root_hash would then return a wrong hash. Loading a stored machine from damaged .dht, .dpt, hash_tree.sht, or hash_tree.phtc files is one way to get there.

verify_hash_tree now updates the hash tree and then checks all of it against memory. If it passes, every hash the machine reports matches the machine state.

• Dense trees. Every page node matches memory, padding pages are pristine, and every inner node matches its children.
• Dirty page trees. No dirty node has a clean parent. Otherwise, later writes would stop marking at that node and never reach the root.
• Sparse tree. Every address-range node matches the root of its dense tree, and every inner node matches its children.
• Page hash-tree cache. Every entry is returned, is indexed by its page address, holds the page as it is in memory, and has a page hash tree that matches that page.

On the first mismatch, it raises an error naming the node, for example dense hash tree node at address 0x80002000 with log2_size 13 (in RAM) does not match its children. On success, it returns the root hash, just like get_root_hash.

The error messages use a new to_hex_string helper in algorithm.hpp.

Breaking changes

• cm_verify_hash_tree(cm_machine *m, cm_hash *hash) returns the root hash instead of a bool, and fails instead of reporting false
• machine:verify_hash_tree() in Lua and machine.verify_hash_tree in JSON-RPC return the root hash and raise an error on mismatch

Tests

spec-hash-tree.lua stores a machine, corrupts one structure on disk in a copy, loads the copy, and checks the error message. The cases cover the dense root, a dense inner node, a dense page node, a padding page node, a dirty node under a clean parent, the sparse root, and the page data, root hash, word hash, and borrowed flag of a cache entry. Two more cases check that an uncorrupted copy returns the stored root hash, and that a corrupted sparse leaf is repaired from its dense root. Existing callers in the Lua and C API tests now compare the returned hash with get_root_hash.

[edubart]

I would add a comment mentioning this operation should be used sporadically because unlikely other hash tree operations it is does not have multi-threaded acceleration.

[diegonehab]

I'm starting to think that, if you don't trust the machine, you should just clear the hash-tree. What do you think, Eduardo? Then we can leave this "verify" function to do what it was meant to do. Which is to see if we screwed up ourselves, not if somebody else screwed with us.

[diegonehab]

I think this is not worth it. It's best to clear and start from scratch.