azure: every evidence generation pays a fixed 3s sleep and an IMDS round-trip

[samlaf]

Main idea: consider a cached HCL report/TD quote with freshness from the TPM quote nonce.

create_azure_attestation (crates/attestation/src/azure/mod.rs) binds
the caller's 64-byte input into the evidence by writing it into the HCL
report's user_data:

let hcl_report_bytes = vtpm::get_report_with_report_data(&input_data)?;

Inside az-tdx-vtpm/az-cvm-vtpm, that call writes the input to a shared NV
index, sleeps a fixed 3 seconds while the paravisor regenerates the HCL
report, and reads it back. Because the report data changes per call, the
TD quote must then also be re-fetched from IMDS on every call. The
consequences:

• every evidence generation costs 3+ seconds of pure sleep plus an IMDS
  round-trip;
• the write→sleep→read sequence over shared NV indices races against any
  concurrent evidence generation on the same VM, so callers must serialize
  evidence generation machine-wide (a mismatched report is caught by
  user_data verification, but the exchange fails and must retry).

An upstream improvement (poll for user_data match instead of the fixed
sleep — filed as kinvolk/azure-cvm-tooling#93) fixes the
latency overhang and the staleness, but not the fundamental contention:
there is one report-data channel per VM.

The evidence document already carries a second binding channel: the TPM
quote is generated over the caller's input (vtpm::get_quote(&input_data[..32])).
If verification relied on the TPM quote's qualifying data plus the AK
provenance chain (TD quote → HCL runtime claims bind the AK → AK
certificate → TPM quote), the HCL report would no longer need
per-exchange report data at all: the HCL report and the TD quote both
become static for the VM lifetime and can be fetched once and cached.
Evidence generation then reduces to a single TPM quote — no NV write, no
sleep, no IMDS round-trip, and safely concurrent (especially over
/dev/tpmrm0, per the companion TCTI issue).

The trade-offs are real, so filing this as a discussion point rather than
a straightforward fix: the caller input would no longer be embedded in the
TDX quote itself (binding moves entirely to the vTPM AK chain), and a
cached TD quote reflects TCB status as of quote time rather than exchange
time. Interested in whether this direction is acceptable, or whether you
would rather keep the per-exchange TD-quote binding and take only the
upstream polling improvement.