Helm | unstable SNP TEE e2e

[Xynnn007]

Firstly meet in https://github.com/confidential-containers/trustee/actions/runs/30064331370/job/89393345540?pr=1508#step:12:646, and when retrigged for sometime, it succeeded.

Note that the diagnose info shows

2026-07-24T03:41:49.484556Z DEBUG attestation_evaluate{request_id=98968aa1-13bc-4767-beee-b348c1a6f18d}:AMD SNP: verifier::snp: failed to fetch vcek from KDS { base_url: None }: Unable to fetch VCEK from URL: 429, "https://kdsintf.amd.com/vcek/v1/Milan/d41e5bee55db6b524d4f8c6e5fbb63635fdf33b1d64a54ee37345eb78408dc3ce278c584544bdd829448281469876d3905b44e0eb727b8070b9be0496d2bfe5b?blSPL=03&teeSPL=00&snpSPL=23&ucodeSPL=213"

Looks like it's network issue or something else. We should use local configured vcek than request from KDS in the test.

[fitzthum]

Yes, pre-provisioning the vcek is a good idea. There's enough info in that log message to get the VCEK offline. This will make things a little more brittle on updates ofc.

[Xynnn007]

Oh. I also see that SNP evidence can carry VCEK certs along with the evidence. The gc code and trustee code

I am not sure if the current SNP runner could be configured to support this? Looks like some firmware stuff?

In this way, we can avoid the verifier side to access KDS.

cc @amd-aliem

[fitzthum]

The extended cert chain can be set on the host and then carried through to the verifier. We used to use this at some point, but there was some churn in how the kernel implemented this (at least in the AMD patchset before it was merged). I am not sure if that feature is supported now or how. Maybe through the HV rather than the kernel. Hopefully someone from AMD can update us on it.

[Xynnn007]

Good. FWIW, that's the best way up to now - or we should have some hardcode vcek in the repo. The hardcode vcek is bound to a specific org runner - which would bring trouble when runner gets out

[fitzthum]

cc @amd-cmaxwell

[amd-aliem]

The extended cert chain can be set on the host and then carried through to the verifier. We used to use this at some point, but there was some churn in how the kernel implemented this (at least in the AMD patchset before it was merged). I am not sure if that feature is supported now or how. Maybe through the HV rather than the kernel. Hopefully someone from AMD can update us on it.

I believe kernel support was recently merged to mainline but unsure if QEMU dependencies are. There should be support in snphost to package certs in the required format for loading. (We had actually happened to chat internally last week about bringing it up at a trustee meeting, but didn't realize it would happen to come up so soon!)

Sorry out of town for this week, but I'll see if I can get someone from my team to provide more details :) Otherwise I'll test it out on Monday.

@fitzthum @Xynnn007

[DGonzalezVillal]

Hello guys,

Apologies, I just got around to looking at this.

Extended attestation is now supported in the kernel as of version 7.0. However, the way the command works is a little different from the original implementation.

Instead of loading the certificates through the kernel command, they are now provided by the hypervisor, as @fitzthum mentioned. QEMU support is expected to land in version 11.2. The certificates need to be placed into the GHCB cert_table format defined here:

https://docs.amd.com/v/u/en-US/56421

The resulting certificate table is then passed to QEMU as a file on the command line.

The snphost tool includes functionality to convert the certificates into the expected format if you want to see how this is done.

On the guest side, the request looks exactly the same, so no changes are needed there.

[amd-aliem]

Thanks @DGonzalezVillal for the info!

@Xynnn007 @fitzthum you might've seen @hgowda-amd's msg in slack but copying it here as well for completeness - since extended attestation not fully supported yet, going to do the offline store route. We loaded our host's current vcek onto our trustee CI CVM yesterday, & team is working on configuring CI tests to mount & use it - probably will configure it as the secondary source so it's a fallback.

Agree that's it's a bit brittle, but team is aware that it'll need to be refreshed on FW update. Currently we have a manually run script to fetch from KDS and load into the CVM w/ appropriate name - we can look into auto-running on startup or FW update event in the future.