AAEL eventlog replay support for az-snp-vtpm

[aramirez-capacity]

Wires the az_snp_vtpm verifier into trustee's generic CoCo eventlog replay, so parsed AAEL events surface as a structured uefi_event_logs claim — matching what the CSV and TDX verifiers already expose. Previously az_snp_vtpm exposed no eventlog claim at all.

The verifier reads each event's target PCR register directly from the eventlog rather than assuming a fixed one, and replays each targeted register independently. A new initial_value field on the shared ReferenceMeasurement type (deps/eventlog) lets a register seed from a non-zero reset value instead of the default all-zero — used here to seed vTPM DRTM registers (PCR17-22) with their TCG-specified 0xFF reset value (see Table 7: https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p05p_r14_pub.pdf). Existing TDX/CSV callers are unaffected (empty initial_value keeps the old zero-seed behavior).

In practice, Azure's vTPM rejects locality-0 extends on PCR17-22 (as discussed here: confidential-containers/guest-components#1605 (comment)), so real AAEL events land on PCR23 instead — reading the target register from the eventlog itself handles this correctly without hardcoding either PCR.

Depends on confidential-containers/guest-components#1605: az_snp_vtpm's get_evidence() doesn't currently attach an eventlog at all, so there's nothing to replay without it. Its own hardware validation hit the same PCR17 locality-0 rejection independently.

Testing

cargo build / test / clippy / fmt --check (eventlog, verifier --features az-snp-vtpm-verifier); one pre-existing clippy warning in an unrelated, untouched test
new unit tests: register-agnostic PCR replay seeding (DRTM vs. non-DRTM registers); initial_value behavior in the shared eventlog crate
validated end-to-end against real Azure SEV-SNP + vTPM hardware: replay succeeds against both an empty eventlog and a populated one (a real image-pull event on PCR23, digest_matches_event: true)

[fitzthum]

First, please see community AI policy, particularly the sections about PR descriptions and comments. This will help the PR reviewed fsater.

Second, please provide some references for the various claims about which PCRs are used.

Also, can you mention that the AZ TDX verifier already exposes the eventlog tcb claim, but does it not have the same problem that you are targeting in the second commit?

[fitzthum]

Should this be an Option? Also, please provide some documentation for this nonzero reset claim.

[Xynnn007]

@aramirez-capacity This non-zero case would cause a problem. If allow non-zero initial value, an malwared attester can fake this field with a non-zero value. Also, trim the eventlog items with only later "good parts", and squash previous "bad parts" into a initial_value here.

Now we assume all fields to be zero-initialized, thus no such attack could happen - as all eventlog entries should be included so reflect the PCR final value.

If we want this field, we should let the verifier explicitly know the expected value and check it. One way is to add this into the parsed claims and let the policy cover this. Also, I suggest to change default policy to assert these fields to be all zeros. This prevents users from inadvertently allowing malicious initial PCR values ​​due to a lack of configuration.

[aramirez-capacity]

The non-zero initial value is part of the spec: https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p05p_r14_pub.pdf (see Table 7).
It's not an arbitrary value; it's either 0 or -1, depending on the PCR.
I added a mention in the comment.

[Xynnn007]

Oh ok. I misunderstood this. Thanks for the explanation. Another question is: Is DRTM the always behavior for Azure thus 17~22 be reset to -1?

[aramirez-capacity]

Confirmed there's no DRTM launch on Azure's SEV-SNP vTPM (az-snp-vtpm).
Here's a live quote showing PCR23 holds a real measurement while PCR17-22 still contain their initial values (0xFF):

"tpm": {
    "pcr00": "13177a6535badf19415c06589705dd5a1890f73545c4a9fef7acfe2c6177a2b7",
    "pcr01": "3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969",
    "pcr02": "3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969",
    "pcr03": "3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969",
    "pcr04": "c35ccf52ab2960710d0b0d90fa81596654dbd25cd21912bb26b2debbf5f14209",
    "pcr05": "0a3d1a92e6542d7a6bc71d199e5fc37f69a5b302bd0f5b4a1a1b15e7f6fc7683",
    "pcr06": "f6a2145d299e1372a74a218637e18fc2f72d791bcd41cead5ffa3697ff64fbeb",
    "pcr07": "3b20e022416fdf61d72e4da32b4354781be3de0608116976d28ffdad8c341d2a",
    "pcr08": "b6bf8a1bd74334f4a79e1b19002af49f4789eb4b25211b0c86d8f01466f0ef42",
    "pcr09": "4282b879e0120876b9f9b3800cf4b72f6eb45178365041223da972fdd07bbbbd",
    "pcr10": "484b9766c2d0615ac214cbce90c36a0b81d89e6fa7f485bce3abc36b40fc7165",
    "pcr11": "04785baf77f36dee740f41bd6758bd2d0a7b48ef7f732d5d1f6268cba008f0f1",
    "pcr12": "f1a142c53586e7e2223ec74e5f4d1a4942956b1fd9ac78fafcdf85117aa345da",
    "pcr13": "0000000000000000000000000000000000000000000000000000000000000000",
    "pcr14": "306f9d8b94f17d93dc6e7cf8f5c79d652eb4c6c4d13de2dddc24af416e13ecaf",
    "pcr15": "0000000000000000000000000000000000000000000000000000000000000000",
    "pcr16": "0000000000000000000000000000000000000000000000000000000000000000",
    "pcr17": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
    "pcr18": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
    "pcr19": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
    "pcr20": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
    "pcr21": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
    "pcr22": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
    "pcr23": "dd21afeb2b2ee07d6754d2fe9be856813aa023e5875445bc46cb1234b7508d42"
  }

[Xynnn007]

cc @mkulke please help to check if this is expected from white box view.

[mkulke]

It should be -1/0xff by the TCG standard, so that's expected I think:

[fitzthum]

This doesn't seem like the right name. This function is doing a lot more than simply adding the eventlog to the claims.

[aramirez-capacity]

Would something like verify_and_extend_eventlog_claim be better?

[mkulke]

fn names that have contain do_x_and_y are a bit smelly, if possible let's have verify_eventlog() and extend_eventlog_claim().

[aramirez-capacity]

Fair. Split the function into verify_eventlog and extend_eventlog_claim.

[Xynnn007]

Thanks @aramirez-capacity . Before diving into the code, an overall design comment.

Also, could you help to make a separate PR for the document updation? I think it can get merged soon.

[Xynnn007]

@aramirez-capacity This non-zero case would cause a problem. If allow non-zero initial value, an malwared attester can fake this field with a non-zero value. Also, trim the eventlog items with only later "good parts", and squash previous "bad parts" into a initial_value here.

Now we assume all fields to be zero-initialized, thus no such attack could happen - as all eventlog entries should be included so reflect the PCR final value.

If we want this field, we should let the verifier explicitly know the expected value and check it. One way is to add this into the parsed claims and let the policy cover this. Also, I suggest to change default policy to assert these fields to be all zeros. This prevents users from inadvertently allowing malicious initial PCR values ​​due to a lack of configuration.

[mythi]

I'm curious if you see all-zeros for the measured boot range <16? My understanding is DRTM is not really applicable in this Azure setup.

[aramirez-capacity]

Not quite. DRTM is not applicable in Azure, but SRTM is.
Here's a quote that shows a real measurement in PCR23 while keeping PCR17-22 (DRTM) at their default values (0xFF), but PCR00-15 do have real measurements too (SRTM):

"tpm": {
    "pcr00": "13177a6535badf19415c06589705dd5a1890f73545c4a9fef7acfe2c6177a2b7",
    "pcr01": "3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969",
    "pcr02": "3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969",
    "pcr03": "3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969",
    "pcr04": "c35ccf52ab2960710d0b0d90fa81596654dbd25cd21912bb26b2debbf5f14209",
    "pcr05": "0a3d1a92e6542d7a6bc71d199e5fc37f69a5b302bd0f5b4a1a1b15e7f6fc7683",
    "pcr06": "f6a2145d299e1372a74a218637e18fc2f72d791bcd41cead5ffa3697ff64fbeb",
    "pcr07": "3b20e022416fdf61d72e4da32b4354781be3de0608116976d28ffdad8c341d2a",
    "pcr08": "b6bf8a1bd74334f4a79e1b19002af49f4789eb4b25211b0c86d8f01466f0ef42",
    "pcr09": "4282b879e0120876b9f9b3800cf4b72f6eb45178365041223da972fdd07bbbbd",
    "pcr10": "484b9766c2d0615ac214cbce90c36a0b81d89e6fa7f485bce3abc36b40fc7165",
    "pcr11": "04785baf77f36dee740f41bd6758bd2d0a7b48ef7f732d5d1f6268cba008f0f1",
    "pcr12": "f1a142c53586e7e2223ec74e5f4d1a4942956b1fd9ac78fafcdf85117aa345da",
    "pcr13": "0000000000000000000000000000000000000000000000000000000000000000",
    "pcr14": "306f9d8b94f17d93dc6e7cf8f5c79d652eb4c6c4d13de2dddc24af416e13ecaf",
    "pcr15": "0000000000000000000000000000000000000000000000000000000000000000",
    "pcr16": "0000000000000000000000000000000000000000000000000000000000000000",
    "pcr17": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
    "pcr18": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
    "pcr19": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
    "pcr20": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
    "pcr21": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
    "pcr22": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
    "pcr23": "dd21afeb2b2ee07d6754d2fe9be856813aa023e5875445bc46cb1234b7508d42"
  }

[mythi]

From confidential-containers/guest-components#1605 I see that writes to PCR17-22 fail. What prevents us to use one of the PCRs that are not used at the moment? Alternatively, we could include full /sys/kernel/security/tpm0/binary_bios_measurements and get the full log the way TDX and CCEL uses replay of all MRs.

[mkulke]

I agree, if we are able to use the standard tcg eventlog, that would be preferable over a custom coco log (if that’s feasible)

[aramirez-capacity]

I believe we are getting sidetracked here. Your comments seem to concern the guest-components side of things. This PR has no say in what PCRs are used or what are the contents of the logs. It simply validates the eventlog (be it CCEL or AAEL) and uses the PCRs defined in the log events themselves.

But to answer your questions:

• PCR23 ("Application Support" in the TCG spec) is already the designated unused / general-purpose register, and it's already what Azure's config targets.
• guest-components' read_eventlog() already tries CCEL first, the same standard mechanism TDX uses, and only falls back to the custom AAEL runtime file when CCEL isn't present. Azure SEV-SNP CVMs just don't expose a CCEL table at all, so there's nothing standard to include there. We don't make an explicit choice to bypass it.
• The AAEL already uses the standard TCG eventlog format. The only custom bit is the payload describing an image pull, because CCEL has no such concept.

Still, I think this is a conversation to be had in the guest-components PR: confidential-containers/guest-components#1605

[mythi]

@aramirez-capacity I believe these two PRs are related so not completely side-tracking here. What's relevant for this PR is the question whether how to handle the replay of 17-22 for Azure vTPMs since they don't seem to work and has impact to initial_value

[mythi]

Also, can you mention that the AZ TDX verifier already exposes the eventlog tcb claim,

This is true for the baremetal TDX only. We don't have the confidential computing eventlog available for Azure TDX VMs.

[aramirez-capacity]

Thanks @aramirez-capacity . Before diving into the code, an overall design comment.

Also, could you help to make a separate PR for the document updation? I think it can get merged soon.

Created a separate PR for the document: #1568

[Xynnn007]

Some code structures are common case. I will take a refactor once this get merged.

[Xynnn007]

When I see lots of code here are about the eventlog generation, I suspect if it's good to be under the azure snp vtpm verifier part. A possible way, is to include some evidence fixtures with eventlog field Option::Some. And do a simple verify_eventlog rstest matrix here.

[aramirez-capacity]

Did the rstest matrix.
Didn't move the helper as neither the TDX nor CSV verifier tests have an equivalent helper today, so I'm not sure how you would like this to be organized.

[Xynnn007]

Yes. I mean no fixture generation code here, but only leave evidence fixtures in https://github.com/confidential-containers/trustee/tree/main/deps/verifier/test_data/az-snp-vtpm

[aramirez-capacity]

Ah, I see. I added the fixtures.

[Xynnn007]

We do not need to mention other verifiers here

[aramirez-capacity]

Dropped the reference.

[Xynnn007]

We could bring this function to https://github.com/confidential-containers/trustee/blob/main/deps/verifier/src/lib.rs as a common helper and use it here.

[aramirez-capacity]

Moved the function to lib.rs.