Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

The os-image-hash RTMR3 event records the key provider's answer, is emitted only on the KMS path, and has no reader

Aberta
  • Algo errado?
#1,291 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Ativa
Stack de tecnologia
rust
Domínio
security

Direção de pesquisa

Start with dstack-util/src/system_setup.rs:2338 and the key-provider paths at :2458-2476, then inspect dstack-attest/src/attestation.rs:1768-1788 and :1990-1993 for the measurement and image-hash readers. Decide which improvement direction is selected, document or implement that direction, and verify that the resulting event semantics and verifier behavior are consistent with the stated goal.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Label: DESIGN. Nothing here is broken; the question is what the measurement commits to and what its name invites a reader to assume.

Base: origin/next @ 030fbb2183.

What the design currently is

dstack-util/src/system_setup.rs:2336-2339:

let response = kms_client.get_app_key(rpc::GetAppKeyRequest { ... }).await?;

emit_runtime_event("os-image-hash", &response.os_image_hash)
    .context("failed to extend os-image-hash to the launch measurement")?;

response is the GetAppKeyResponse. The payload extended into RTMR3 is therefore the KMS's answer, not anything the guest computed or observed.

Three properties follow:

  1. The value is the key provider's assertion. When key_provider_id is unpinned in app-compose — the default — verify_key_provider_id returns Ok(()) on an empty pin (system_setup.rs:2390-2393), and kms_urls comes from the host-supplied .sys-config.json (system_setup.rs:2364-2384). .agent/THREAT-host-and-app.md H-4 establishes that a host can point kms_urls at a KMS it operates inside a genuine TEE and nothing in the guest refuses it. In that configuration the host chooses this event's payload.
  2. It is emitted only on the KMS path. KeyProviderKind::Local, Tpm and None (system_setup.rs:2458-2476) produce no os-image-hash event at all, so its absence carries no information.
  3. Nothing reads it. rg 'os-image-hash' across dstack/, sdk/ and docs/ returns the producer at :2338, the KMS's own test fixtures, and no consumer. AppInfo.os_image_hash is read from vm_config (dstack-attest/src/attestation.rs:1990-1993), never from this event.

Reachability

  • Who can trigger it: the host, by selecting kms_urls, whenever the tenant has not pinned key_provider_id.
  • What credential it needs: the ability to run a KMS that passes attestation — no tenant or operator credential.
  • Who controls frequency: the host, every boot.

Steelman

Extending it is defence in depth. It makes the image identity the guest was told about part of mr_aggregated (dstack-attest/src/attestation.rs:1768-1788), so any attestation taken after key release commits to it, and a future verifier could cross-check it against vm_config for free. Emitting it at the point where the value first becomes known to the guest is the natural place to put it, and the .context() message shows the intent was precisely "make this part of the launch measurement".

It is also genuinely harmless today, because nothing consumes it.

What it costs

An event named os-image-hash sitting in a hardware-measured log invites a relying party to read it as the image identity. It is not that. It is "what my key provider told me my image hash is", and on the default configuration the host picks the key provider. A reader who does the obvious thing gets a host-influenced value carrying the authority of RTMR3.

This is a naming and documentation cost rather than a live bypass — but the whole point of an event log is that a third party can read it without knowing the emitter's internals.

Improvement directions

  1. Cheapest, and the minimum. A one-line comment at system_setup.rs:2338 recording that the payload is the provider's claim, not a guest observation. Stops the next reader from treating it as evidence. Zero risk, no measurement change.
  2. Cheap and additive — the useful one. Have the verifier compare find_event_payload("os-image-hash") against vm_config.os_image_hash when the event is present, and surface the result. That turns a write-only measurement into an actual check, costs nothing on boots that do not emit it (see property 2 above), and composes with the os_image_hash_anchor direction in #1266.
  3. Rename to say whose claim it is — kms-os-image-hash, or fold it into the existing key-provider event payload, which already carries provider name and id (system_setup.rs:980-985). This changes RTMR3 for every image, so it is a measured-value change: it belongs with the next event_log_version bump (dstack-attest/src/lib.rs:90-121), not on its own. Listed for completeness, not recommended as a standalone change.

(1)+(2) are cheap and independent. (3) is a deployment event.

Linguagem predominante
Rust
Estrelas
561
Forks
99
Merge médio
1d 5h
PRs com merge (30d)
182

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de Dstack-TEE/dstack

Todas as issues de Dstack-TEE/dstack

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.