You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Second PR in a 3-part stack implementing an optional dm-verity root hash signature partition. Builds on #834.
This PR introduces COSI metadata specification version 1.3, carrying the same data/signature linkage as the HostConfiguration API addition in #834, and wires derivation of the new field when building a Host Configuration from a COSI image.
Changes
KnownMetadataVersion::V1_3 — documents the new spec version.
VerityMetadata.signature: Option<ImageFile> — optional detached PKCS#7/DER signature of the root hash, stored in its own partition.
filesystem_image_files() includes the signature file, so existing v1.2 partition-matching/size/hash validation automatically covers it (no new error variants needed).
derive_host_configuration_inner derives VerityDevice.signature_device_id by resolving the signature image's partition, mirroring the existing hash-partition derivation.
OsImageVerityHash.signature_image_file carries the mapped file through to the engine layer (consumed in PR3).
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.
Introduces COSI metadata specification version 1.3, adding an
optional `signature` field to `VerityMetadata` that points at an
ImageFile holding a detached PKCS#7/DER signature of the verity root
hash.
- `KnownMetadataVersion::V1_3` documents the new version.
- `filesystem_image_files()` includes the signature file so existing
V1_2 partition-matching/size/hash validation covers it automatically.
- `derive_host_configuration_inner` derives
`VerityDevice.signature_device_id` by resolving the signature
image's partition, linking the COSI image to the new HostConfig
API field from the previous PR in this stack.
- `OsImageVerityHash.signature_image_file` carries the mapped file
through to the engine layer.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Addresses review feedback on PR #835:
- Document the COSI 1.3 revision (signature field on VerityConfig) in
Composable-OS-Image.md, with a changelog entry and revision summary row.
- Publish cosi-metadata-v1.3.schema.json alongside matching valid/invalid
samples validated by the existing schema-validation workflow.
- Add a derive_host_configuration_inner test exercising a non-None
VerityMetadata.signature, asserting the derived hash_signature_device_id
resolves to the correct partition.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Addresses review feedback on PR #835:
The v1.3 verity-uki-systemd-boot.json sample declared a signature
stored in a dedicated partition, but disk.gptRegions only listed the
ESP and root partitions - no matching region for the root-verity hash
or root-verity-sig partitions the verity block itself references.
This made the sample schema-valid but not something Trident's own
partition-consistency checks could ever accept as a real COSI file.
Added matching gptRegions entries (partition numbers 3 and 4) for the
hash and signature images, reusing their existing ImageFile metadata
from the verity block so they stay byte-for-byte consistent.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ions
Addresses follow-up review feedback on PR #835:
Adding GPT regions for the hash and signature partitions (previous
commit) made the sample internally consistent for partition
references, but the disk's declared size (1 GiB) was never big enough
to hold all four partition images (esp + root + root-verity hash +
root-verity-sig), which together need at least ~1.43 GiB uncompressed.
Enlarged disk.size to 2 GiB, comfortably above that total.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Issue: A signature can alias the data or hash image path even though it must occupy its own dedicated partition. Evidence: this iterator is collected into a HashMap keyed by path in validation.rs:150-153; adding signature here means a duplicate path silently overwrites the earlier image, so validation may ignore one image's metadata and derivation can assign the same partition ID to both hash and signature devices. Suggestion: reject duplicate paths among filesystem, verity-hash, and signature image references before building the path map, and add a regression test for an aliased signature path.
Require DER-encoded detached PKCS#7 signatures
docs/Reference/Composable-OS-Image.md:295
Issue: The v1.3 contract does not require the signature to use DER encoding. Evidence: this field permits an unspecified PKCS#7 representation, while the stacked consumer in #836 passes the raw partition directly to veritysetup and explicitly relies on PKCS#7/DER being self-delimiting so partition padding is safe. A producer following this text could emit PEM or another encoding that is not compatible with that consumption model. Suggestion: specify that this MUST be a DER-encoded detached PKCS#7 signature here and in the v1.3 schema description.
Great comments. Addressed both previously missed findings from review 5479586725 in fbee98e: duplicate filesystem/hash/signature role paths are rejected before map construction, and the specification/schema explicitly require DER-encoded detached PKCS#7 signatures. Added aliasing regression coverage while retaining valid disk-region references.
This branch has not been deployed
No deployments
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
bfjelds (bfjelds)
changed the title
Summary
Second PR in a 3-part stack implementing an optional dm-verity root hash signature partition. Builds on #834.
This PR introduces COSI metadata specification version 1.3, carrying the same data/signature linkage as the HostConfiguration API addition in #834, and wires derivation of the new field when building a Host Configuration from a COSI image.
Changes
KnownMetadataVersion::V1_3— documents the new spec version.VerityMetadata.signature: Option<ImageFile>— optional detached PKCS#7/DER signature of the root hash, stored in its own partition.filesystem_image_files()includes the signature file, so existing v1.2 partition-matching/size/hash validation automatically covers it (no new error variants needed).derive_host_configuration_innerderivesVerityDevice.signature_device_idby resolving the signature image's partition, mirroring the existing hash-partition derivation.OsImageVerityHash.signature_image_filecarries the mapped file through to the engine layer (consumed in PR3).Stack
Testing