hash-signature (3): deploy and open verity root hash signature partitions by bfjelds · Pull Request #836 · microsoft/trident

bfjelds (bfjelds) · 2026-10-08T16:09:45Z

Summary

Third and final PR in a 3-part stack implementing an optional dm-verity root hash signature partition. Builds on #835.

This PR implements install/update support: Trident can now deploy a COSI's signature partition content and use it when opening verity devices.

Changes

deploy_images streams the signature partition's content from the OS image when both the image and the Host Configuration declare a signature device. Errors clearly if only one side declares it (misconfiguration).
setup_verity_devices prefers the new declarative signature partition when VerityDevice.signature_device_id is set:
- Reads the PKCS#7/DER signature directly from the raw block device — no mount required, since DER encoding is self-delimiting and tolerates trailing zero-padding.
- Writes it to a temp file and opens the verity device with veritysetup open --root-hash-signature=....
- Falls back to the existing internal_params.veritySignaturePaths file-based mechanism, then to a plain open(), preserving behavior when no signature partition is configured.

Stack

Testing

validated entire stack: https://dev.azure.com/mariner-org/ECF/_build/results?buildId=1220444&view=results
prism w/ IC and Trident changes: https://dev.azure.com/mariner-org/ECF/_build/results?buildId=1220451&view=results

azure-pipelines · 2026-10-08T16:09:55Z

Azure Pipelines: 1 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

Implements install/update support for the optional verity root hash signature partition introduced in the previous two PRs of this stack. - `deploy_images` streams the signature partition's content from the OS image when both the image and the Host Configuration declare a signature device; errors if only one side declares it. - `setup_verity_devices` prefers the new declarative signature partition when `VerityDevice.signature_device_id` is set: reads the PKCS#7/DER signature directly from the raw block device (no mount needed, since the DER encoding is self-delimiting), writes it to a temp file, and opens the verity device with `veritysetup open --root-hash-signature=...`. Falls back to the existing `internal_params.veritySignaturePaths` file-based mechanism, then to a plain open, preserving prior behavior when no signature partition is configured. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Construct the special storage-graph reference connecting a verity device to its optional root hash signature device. This activates the validation rules added in the HostConfig API PR (restricting the signature device to a LinuxGeneric partition, enforcing homogeneous partition types, etc.), and is paired with the engine-side install/update support in this PR.

Copilot

🟡 Changes recommended

Reading an entire potentially grow-sized partition into memory risks exhausting memory and temporary storage.

2 open findings

Bound signature reads to prevent memory and temporary-file exhaustion · New
Add test coverage for hash signature device handling · New

What changed in this PR

Adds deployment and activation support for optional dm-verity root-hash signature partitions.

Changes:

Deploys signature images with verity data and hash images.
Opens verity devices using signatures read from dedicated partitions.
Adds signature partitions to storage dependency graphs.

File	Description
`crates/trident/src/engine/storage/verity.rs`	Reads partition signatures and opens signed verity devices.
`crates/trident/src/engine/storage/image.rs`	Deploys signature partition images.
`crates/trident_api/src/config/host/storage/storage_graph/references.rs`	Activates the signature reference kind.
`crates/trident_api/src/config/host/storage/storage_graph/node.rs`	Adds configured signature devices to graph references.

🧠 Review effort: Balanced

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Addresses review feedback on PR #836: - Bound the number of bytes read from a dedicated verity root hash signature partition (extracted into read_signature_partition_bytes) instead of fs::read()-ing the whole block device. A Grow-sized signature partition can no longer be read entirely into memory; oversized partitions are now rejected with a clear error. - Add unit tests: read_signature_partition_bytes bounds enforcement, and a setup_verity_devices test proving the declarative hash_signature_device_id path takes precedence over the legacy veritySignaturePaths internal parameter. While adding that precedence test, found and fixed a latent bug it would otherwise have hit: BlkDevReferrerKind::VerityDevice::valid_target_count() was still hardcoded to exactly 2 targets, so any verity device that actually sets hash_signature_device_id (the whole point of this feature) fails storage graph validation with InvalidTargetCount before ever reaching the engine. Widened to accept 2-3 targets. All existing trident_api/trident unit tests (195 + 407) still pass. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

🟡 Changes recommended

Signature partitions larger than 1 MiB are incorrectly rejected based on partition capacity rather than DER payload length.

1 open finding

Use signature length instead of block device capacity · New

2 resolved since last review

Bound signature reads to prevent memory and temporary-file exhaustion
Add test coverage for hash signature device handling

🧠 Review effort: Balanced

…setup Addresses review feedback on PR #836 (and supersedes my own earlier fix to the same code, which was still wrong): open_verity_device_with_signature_partition used to read the signature partition's bytes into memory (bounded by an arbitrary 1 MiB cap) and copy them into a temporary file for veritysetup. That cap was itself broken: block-device reads don't EOF until the partition ends, and deployment doesn't truncate/zero the tail beyond the real image bytes, so any real signature partition sized (e.g. via PartitionSize::Grow) past 1 MiB would be rejected even though the actual DER payload inside it is tiny. The deeper problem was reading the bytes at all. `veritysetup --root-hash-signature=FILE` and the existing open_with_signature() wrapper just take a path - there's no distinction between a regular file and a block device special file, and both `open()`/`read()` identically either way. The PKCS#7/DER blob is self-delimiting, so whatever parses it stops at the structurally-defined length regardless of trailing zero-padding. Trident's job for this partition should stop exactly where it stops for the hash partition: deploy the COSI image bytes onto the right partition (already handled uniformly for every image via deploy_os_image_file's uncompressed_size-bounded stream), and nothing else - no read-back, no cap, no temp file. Deleted read_signature_partition_bytes and the temp-file copy entirely; the signature partition's resolved device path is now passed directly to open_with_signature, exactly like data_device_path/hash_device_path already are. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

🟡 Changes recommended

veritysetup rejects the supplied block-device path because root-hash signatures must be regular files.

1 open finding

Signed activation rejects partition path as signature file · New

1 resolved since last review

Use signature length instead of block device capacity

🧠 Review effort: Balanced

Copilot

🔵 Needs a closer look

veritysetup rejects block devices as signature files, making the new signed activation path fail.

1 open finding

Signed activation rejects partition path as signature file

🧠 Review effort: Balanced

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d61c42e7-3c43-4fe5-8c89-89d38ff9528b

bfjelds (bfjelds) changed the title ~~engine: deploy and open verity root hash signature partitions~~ hash-signature (3): deploy and open verity root hash signature partitions Oct 8, 2026

bfjelds (bfjelds) force-pushed the user/bfjelds/verity-roothash-sig-3-engine branch from 965932e to 078cfed Compare October 8, 2026 16:39

bfjelds (bfjelds) force-pushed the user/bfjelds/verity-roothash-sig-2-cosi branch from 1d1a60b to 65226af Compare October 8, 2026 16:39

bfjelds (bfjelds) force-pushed the user/bfjelds/verity-roothash-sig-3-engine branch from 078cfed to fe4e3e3 Compare October 8, 2026 16:58

bfjelds (bfjelds) force-pushed the user/bfjelds/verity-roothash-sig-2-cosi branch 2 times, most recently from 1021d24 to 9ca9233 Compare October 8, 2026 17:08

bfjelds (bfjelds) force-pushed the user/bfjelds/verity-roothash-sig-3-engine branch from fe4e3e3 to 75b556c Compare October 8, 2026 17:08

bfjelds (bfjelds) and others added 2 commits October 8, 2026 17:50

bfjelds (bfjelds) force-pushed the user/bfjelds/verity-roothash-sig-2-cosi branch from 9ca9233 to 6da83e1 Compare October 8, 2026 17:51

bfjelds (bfjelds) force-pushed the user/bfjelds/verity-roothash-sig-3-engine branch from 75b556c to b1e1993 Compare October 8, 2026 17:51

bfjelds (bfjelds) requested a balanced review from Copilot October 8, 2026 19:25

Copilot started reviewing on behalf of bfjelds (bfjelds) October 8, 2026 19:25 View session

Copilot AI reviewed Oct 8, 2026

View reviewed changes

Comment thread crates/trident/src/engine/storage/verity.rs Outdated

Comment thread crates/trident/src/engine/storage/verity.rs

This was referenced Oct 8, 2026

hash-signature (1): add optional verity root hash signature #834

Draft

hash-signature (2): v1.3 spec with optional verity signature partition #835

Draft

bfjelds (bfjelds) requested a balanced review from Copilot October 8, 2026 21:20

Copilot started reviewing on behalf of bfjelds (bfjelds) October 8, 2026 21:21 View session

Copilot AI reviewed Oct 8, 2026

View reviewed changes

Comment thread crates/trident/src/engine/storage/verity.rs Outdated

bfjelds (bfjelds) commented Oct 8, 2026

View reviewed changes

Comment thread crates/trident/src/engine/storage/verity.rs Outdated

bfjelds (bfjelds) requested a balanced review from Copilot October 8, 2026 23:08

Copilot started reviewing on behalf of bfjelds (bfjelds) October 8, 2026 23:09 View session

Copilot AI reviewed Oct 8, 2026

View reviewed changes

Comment thread crates/trident/src/engine/storage/verity.rs Outdated

bfjelds (bfjelds) requested a balanced review from Copilot October 10, 2026 15:21

Copilot started reviewing on behalf of bfjelds (bfjelds) October 10, 2026 15:22 View session

Copilot AI reviewed Oct 10, 2026

View reviewed changes

Merge signature metadata and partition type fixes

aff9f12

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d61c42e7-3c43-4fe5-8c89-89d38ff9528b

fix: extract bounded DER signatures before verity activation

ed7e8b7

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d61c42e7-3c43-4fe5-8c89-89d38ff9528b

Navigation Menu

Repository navigation

hash-signature (3): deploy and open verity root hash signature partitions - #836

hash-signature (3): deploy and open verity root hash signature partitions#836
bfjelds (bfjelds) wants to merge 6 commits into
user/bfjelds/verity-roothash-sig-2-cosifrom
user/bfjelds/verity-roothash-sig-3-engine

bfjelds (bfjelds) commented Oct 8, 2026 •

edited

Loading

Uh oh!

azure-pipelines Bot commented Oct 8, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

bfjelds (bfjelds) commented Oct 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Stack

Testing

Uh oh!

azure-pipelines Bot commented Oct 8, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🔵 Needs a closer look

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

bfjelds (bfjelds) commented Oct 8, 2026 •

edited

Loading