summaryrefslogtreecommitdiff
path: root/scripts/basic
diff options
context:
space:
mode:
authorTom Rini <[email protected]>2026-08-10 12:32:48 -0600
committerTom Rini <[email protected]>2026-08-10 12:37:16 -0600
commit6ea67890d034c8f285dcea438dcee2e06af3921c (patch)
treee28d966945f8a2f359044c661785e9b887f55366 /scripts/basic
parent28515d7ff5285e0b942f15577e3198f15c667a25 (diff)
parentfe9877c7d9dea740985edd11f7ff583e311568be (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