Fetch KDS cert logic fails on non-Milan machines #591
Labels
bug
Something isn't working
Comments
|
Are you interested in this? @AdithyaKrishnan |
|
Yes, I'll create a PR to address this very soon. |
|
Hey guys, I am assuming we need to update to sev 5.0 to enable extracting those values from v3 attestation report? Also, is there any status to resolving this bug? |
|
I have this KDS URL derivation logic present in a Go library you can base a solution off https://github.com/google/go-sev-guest/blob/main/verify/verify.go#L742 |
AdithyaKrishnan
added a commit
to AdithyaKrishnan/trustee
that referenced
this issue
Jan 24, 2025
Part of the solution for Issue [confidential-containers#591](confidential-containers#591) Modifications to the fetch_vcek_from_kds function will be pushed in a follw-up PR very soon Signed-off-by: Adithya Krishnan Kannan <[email protected]>
|
Waiting for PR #268 to be tested and merged before proceeding with decoding the attestation report Version 3 to fetch the CPU ID and model ID for determining the processor generation. CC'ing @DGonzalezVillal |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
fetch_vcek_from_kds is a fallback mechanism when extended guest requests fail to provide a cached VCEK certificate to the guest. The solution in PR #555 hardcodes "Milan" in the endpoint. This will not work for Genoa, Turin, or later products because of the baked-in model string. You can extract the family and model number from attestation report v3 by
family is zen3/zen4 (19h) and map model 0 to "Milan", 1 to "Genoa", or
family is zen5 (1Ah) and map model 2 to "Turin".
How to reproduce
Don't provide cached VCEK to a SEV-SNP VM and verify attestation on Genoa or later.
CoCo version information
latest
What TEE are you seeing the problem on
Snp
Failing command and relevant log output
No response
The text was updated successfully, but these errors were encountered: