dm-verity is a read-only Linux device-mapper target that checks the integrity of a block device on the fly. Hashes sit in a tree, blocks are verified as they are read, and a read that cannot be verified up to the root hash fails. Optional settings can instead log, restart or panic.
The hash tree
According to the kernel documentation, leaf nodes hold hashes of data blocks and each higher node hashes a group of its children. The top is the root hash. Because checks happen on demand, you do not pay to verify an entire partition at boot, only the blocks you actually read.
The root hash is the thing you must trust
The kernel docs are blunt about this. The root hash is supplied as a parameter along with the salt, and it must be trusted, because nothing else vouches for it. You can optionally verify a PKCS#7 signature of the root hash against a kernel keyring when the device is created.
So dm-verity does not remove the need for a trusted start. It moves the question to where the root hash comes from, which is usually a signed boot image or partition table that secure boot has already verified.
What happens on a bad block
By default, a block that does not verify up to the root causes the I/O to fail. The documentation lists settings that change the response:
- ignore_corruption logs corrupted blocks but lets reads proceed.
- restart_on_corruption restarts the system.
- panic_on_corruption panics the device.
Matching options exist for I/O errors. For a production device, ignoring corruption defeats the purpose, so reserve it for debugging.
Forward error correction
Optional Reed-Solomon parity data can recover corrupted or unreadable blocks. Recovered blocks are still checked against the expected hash before use. This helps with non-malicious damage such as flash wear, while not opening a way around the integrity check.
The performance option
The check_at_most_once setting verifies data blocks only on the first read. That lowers overhead, but the documentation says it detects only offline tampering. If an attacker can alter storage while the system runs, a block checked once is no longer protected.
Practical advice
- Use dm-verity for read-only partitions such as the root filesystem, and keep writable data separate.
- Tie the root hash to a signed image so it cannot be swapped.
- Pick a corruption response and test it, including what the user sees.
- Add a recovery path, since a device that panics on every boot is still a failed device.
Quick check
Does dm-verity work on writable filesystems?
It is a read-only target. Keep writable data on a separate partition.
What happens if the root hash is replaced?
Verification would pass against the attacker's hash. That is why the root hash must come from a trusted, verified source.
Where Safeguard fits
Safeguard works on the software supply chain around your firmware: SBOM and dependency scanning, policies and gates that can block a release, and compliance evidence. It does not sign images or run your bootloader. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
