Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,291 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
rust
Área
security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
555
Forks
97
Merge medio
1 d 3 h
PR fusionados (30 d)
195

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Dstack-TEE/dstack

Todos los issues de Dstack-TEE/dstack

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.