confidential-containers
Fetch KDS cert logic fails on non-Milan machines
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
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
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
@DGonzalezVillal and all, wanna say you guys are doing an amazing work. I recently ran into this same demand on Azure. The NCCads_H100_v5 series is based on Genoa. Can't wait to see attestation of it with cGPU. Keep it up!
