fix: add unpadded init_data hashes to RVPS for bare metal SNP#23
Open
jensfr wants to merge 1 commit into
Open
Conversation
Commit f928983 ("feat: add baremetal TDX/SNP and NVIDIA GPU attestation support") added zero-padded raw hashes to the RVPS init_data reference values, described as "SHA256(toml) zero-padded to 48 bytes for baremetal TDX/SNP". However, SNP and TDX store the init_data hash in different fields with different sizes: - TDX uses mr_config_id (48 bytes), so the 32-byte SHA-256 hash is zero-padded to 48 bytes (96 hex chars). The padded format is correct for TDX. - SNP uses host_data (32 bytes), so the SHA-256 hash is stored as-is with no padding (64 hex chars). This is confirmed in the KBS SNP verifier (deps/verifier/src/snp/mod.rs), which calls regularize_data(hash, 32, "HOST_DATA", "SNP") and emits hex::encode(report.host_data) as the init_data claim. Because the RVPS only contained the padded (96-char) format, the OPA policy check failed on bare metal SNP: the 64-char init_data from the attestation report did not match any value in the reference list. Add $rawHash and $debugRawHash (unpadded) to the RVPS alongside the existing padded values. This supports both TDX (padded) and SNP (unpadded) from a single configuration. Fixes: f928983 ("feat: add baremetal TDX/SNP and NVIDIA GPU attestation support") Signed-off-by: Jens Freimann <jfreiman@redhat.com> Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
The RVPS init_data reference values only contain zero-padded (96-char) raw hashes, which breaks attestation on bare metal AMD SEV-SNP.
SNP and TDX store the init_data hash in different hardware fields with different sizes:
mr_config_id(48 bytes) → 32-byte SHA-256 hash is zero-padded to 48 bytes (96 hex chars) ✓host_data(32 bytes) → SHA-256 hash is stored as-is, no padding (64 hex chars) ✗The KBS SNP verifier confirms this in
deps/verifier/src/snp/mod.rs:regularize_data(hash, 32, "HOST_DATA", "SNP")— expects 32 byteshex::encode(report.host_data)— emits 64 hex chars as theinit_dataclaimThe OPA policy
input.init_data in query_reference_value("init_data")fails because the 64-char hash from SNP is not in the RVPS list that only has 96-char padded values.Fix
Add
$rawHashand$debugRawHash(unpadded, 64-char) to the RVPS reference values alongside the existing padded versions. This supports both TDX (padded) and SNP (unpadded).Test plan
🤖 Generated with Claude Code