Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#73 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
azure, rust
Ambito
backend, security

Direzione di ricerca

Inizia da create_azure_attestation in crates/attestation/src/azure/mod.rs e segui vtpm::get_report_with_report_data e vtpm::get_quote. Confronta il report HCL memorizzato nella cache e la proposta di TD quote con la verifica esistente e la catena di provenienza di AK, inclusi i compromessi tra concorrenza e freschezza del TCB. Il completamento richiede una decisione di un maintainer sull’accettabilità di questa modifica al binding oppure sulla necessità di perseguire invece il miglioramento upstream del polling.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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 https://github.com/kinvolk/azure-cvm-tooling/issues/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.

Lingua principale
Rust
Stelle
6
Fork
3
Merge medio
2g 20h
PR unite (30g)
3

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di flashbots/attested-tls

Tutte le issue di flashbots/attested-tls

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.