diff options
| author | Tom Rini <[email protected]> | 2026-08-10 12:32:48 -0600 |
|---|---|---|
| committer | Tom Rini <[email protected]> | 2026-08-10 12:37:16 -0600 |
| commit | 6ea67890d034c8f285dcea438dcee2e06af3921c (patch) | |
| tree | e28d966945f8a2f359044c661785e9b887f55366 /scripts/basic | |
| parent | 28515d7ff5285e0b942f15577e3198f15c667a25 (diff) | |
| parent | fe9877c7d9dea740985edd11f7ff583e311568be (diff) | |
Merge patch series "boot: fit: authenticate the dm-verity roothash"
Daniel Golle <[email protected]> says:
A signed FIT configuration can delegate the integrity of a (potentially
large) root filesystem image to the kernel's dm-verity instead of having
U-Boot hash the whole payload at boot: the FIT carries a "dm-verity"
subnode with the roothash, salt and block parameters, U-Boot passes the
roothash to Linux through the dm-mod.create bootargs, and dm-verity then
validates the filesystem block by block against it.
For that to be safe the roothash has to be trusted, and in a signed
configuration the only thing that establishes trust is the configuration
signature. The roothash was not covered by it. fit_config_add_hash()
collected the image node, its hash subnodes and its cipher subnode into
the signed region, but not the dm-verity subnode, so the roothash, the
sole integrity anchor for the filesystem, was left unsigned.
The result is a verified-boot bypass for the root filesystem: an
attacker who can rewrite the boot medium can replace the filesystem,
recompute a matching dm-verity tree, write the new roothash into the
unsigned dm-verity subnode, and the configuration signature still
verifies. dm-verity then faithfully validates the malicious filesystem
against the attacker's roothash.
This series closes the gap.
Link: https://lore.kernel.org/r/[email protected]
Diffstat (limited to 'scripts/basic')
0 files changed, 0 insertions, 0 deletions
