Add V-PROGRAM message type and SEV-SNP trusted execution mode

[odesenfans]

Adds the protocol schema for SEV-SNP confidential VMs, per the design in
aleph-vm docs/plans/2026-07-08-confidential-vm-protocol-design.md:

• New V-PROGRAM message type (VerifiableProgramMessage /
  VerifiableProgramContent): measured runtime bundle ref, verity-bound
  workload volume (data image + hash tree + roothash), platform-tagged
  launch-measurement annotations (LaunchMeasurement), credit-only payment,
  optional attestation_port.
• TrustedExecutionEnvironment gains an optional sev_snp mode (runtime
  bundle ref, measurements, attestation_port) alongside the untouched legacy
  SEV flow; SEV-SNP instances are credit-only.

Deviations from the design doc, for wire stability:

• mode is Optional with None = legacy SEV, instead of defaulting to
  "sev", so legacy content dumps are unchanged (verified byte-identical
  model_dump(exclude_none=True) for all pre-existing fixtures).
• policy keeps its int type and SEV default; SNP mode enforces an
  explicit SNP-valid policy via validate_snp_policy (reserved bit 17 plus
  unsigned-64-bit range, shared by both models).

Implementation notes:

• validate_snp_policy coerces via int(): on Python 3.14 a plain
  (int, Enum) member (the field default AMDSEVPolicy.NO_DBG) no longer
  supports format(..., "#x").
• One # type: ignore[assignment] in vprogram.py on the environment
  override: VerifiableProgramEnvironment deliberately does not join the
  base union (that would wrongly allow it on Instance/Program); pydantic v2
  supports the field re-declaration at runtime.
• New tests live in aleph_message/tests/test_vprogram.py (29 tests) plus a
  fixture message exercising the inline check_content dump-equality path.

Update (2026-07-09): review feedback wave

Attestation-as-a-protocol discussion plus schema tightening (commits 6ab1597, 08898ec, net effect):

• ConfidentialRuntime renamed to VerifiableProgramRuntime: the defining property is verifiability, not confidentiality. runtime.ref now points at the runtime manifest, a small store object pinning the OVMF/kernel/initrd/verity-rootfs artifacts by content hash and declaring the cmdline template, boot format, and attestation protocols (protocol identity is modeled as namespaced, versioned descriptors in the manifest, not in the message: a pure copy of immutable content-addressed data would be denormalization without the checked-redundancy payoff that measurements have). The former attestation_port is gone too: the port is a runtime property (the current init hardwires it); a measured per-deployment override can be added schema-additively if a use case appears.
• aleph_api dropped from VerifiableProgramEnvironment: legacy program-runtime concept; a host-injected API channel has no place inside a measured TCB.
• volumes are now VerifiedVolume only (same ref/hash_tree/roothash triple as the workload, max 8): unverified extra volumes would be attacker-controllable input inside an attested VM (content substitution, malicious-filesystem kernel attack surface). Binding is positional through the measured cmdline (verified_volumes=h1,h2,...); there is deliberately no mount field, since an unmeasured mount mapping would allow volume permutation. Use case: large shared read-only data (LLM weights) without baking it into every workload image.
• variables and authorized_keys rejected on V-Programs: both are unmeasured host-to-guest input channels. Workload env belongs in the verity-bound workload contract; host SSH-key injection has no place in an attested VM.
• Canonical cross-SDK fixture: item_hash is now 4c319b6bdf98f1e90f2bf8c69da175679fa21ca27d4547bbfa32f77dd3b49fe6 (environment/volumes shapes changed; the fixture now exercises a verified volume). aleph-rs #297 and pyaleph #1220 fixtures must be regenerated to match.

🤖 Generated with Claude Code

[foxpatch-aleph]

Well-structured PR that adds V-PROGRAM message type and SEV-SNP TEE mode with careful attention to wire stability. The optional mode field ensures legacy SEV content dumps are byte-identical. Validation is thorough: SNP policy bounds checking, digest length enforcement per platform, credit-only payment enforcement for both V-Programs and SNP instances, and proper field exclusivity between SEV and SNP modes. All 29 new tests pass and existing tests show no regressions. Minor test coverage gaps (explicit mode="sev", TEE attestation_port in SNP mode, check_content rejection path) are non-blocking.

aleph_message/models/__init__.py (line 415): The check_content validator is a verbatim copy of ProgramMessage.check_content (line 387). Consider extracting to a shared helper or mixin to avoid drift — any future fix to one must be manually replicated in the other. This is consistent with the existing pattern though, so not blocking.

aleph_message/tests/test_vprogram.py (line 307): Missing test for mode="sev" (explicit legacy SEV). The validator handles it correctly (falls through to the else branch), but there's no assertion that explicit mode="sev" with firmware works while mode="sev" with runtime is rejected.

aleph_message/tests/test_vprogram.py (line 269): Missing test for attestation_port on TrustedExecutionEnvironment in SNP mode. The V-Program attestation_port is tested (line 204), but the TEE-level attestation_port is only covered indirectly by the sev_forbids_snp_fields test. A positive test (valid port in SNP TEE) and boundary test (port 0 / 65536 in SNP TEE) would close the gap.

aleph_message/tests/test_vprogram.py (line 224): The test_vprogram_message_machine test exercises the check_content happy path (item_content matches content), but no test verifies that check_content actually rejects a mismatched item_content. A test that tampers with item_content after hash computation (bypassing the item_hash validator) would close this gap.

[foxpatch-aleph]

Well-structured PR that cleanly adds the V-PROGRAM message type and SEV-SNP TEE mode. The wire-stability strategy (optional mode field with None = legacy SEV) is sound and verified by the dump-equality test. Validation logic is thorough: SNP policy bit-17 enforcement, mode-field consistency checks, credit-only payment enforcement for both V-Programs and SNP instances, and negative-policy bounds guarding against Python's arbitrary-precision integer semantics. The AttestationProtocol descriptor model is well-designed with an open namespaced identifier space. Test coverage is comprehensive at 29 tests covering valid/invalid paths for all new models. No bugs, security issues, or correctness problems found. The only observations are minor: duplicated check_content validator (matches existing pattern), no explicit test for mode="sev" on TEE, and the attestation_port field on TrustedExecutionEnvironment remains pending migration to the descriptor model (acknowledged in PR description).

aleph_message/models/__init__.py (line 414): The check_content field validator is an exact copy of ProgramMessage.check_content (lines 386-400). Consider extracting it to a shared utility or mixin to avoid duplication. Not blocking — matches the existing pattern where ProgramMessage already has this code.

aleph_message/models/execution/environment.py (line 296): There's no test for mode="sev" (explicitly set, not None). The else branch handles it identically to mode=None, but a test confirming mode="sev" with firmware set is accepted (and that mode="sev" with runtime set is rejected) would close the coverage gap.

aleph_message/tests/test_vprogram.py (line 222): The test case "a" * 63 + ".b" * 2 for the length-cap rejection is not immediately readable — it produces a 67-char string. A comment with the total length or a simpler construction like "a." * 33 (66 chars) would make the intent clearer.

aleph_message/models/execution/environment.py (line 279): The attestation_port field on TrustedExecutionEnvironment (instance-side) uses a simple int, while V-Programs use the new AttestationProtocol descriptor list. The PR description acknowledges this as a follow-up. Noting it here for traceability — the divergence is intentional and temporary.

[foxpatch-aleph]

Well-designed, security-conscious PR adding the V-PROGRAM message type and SEV-SNP TEE mode. All 33 new tests pass, wire stability for existing fixtures is verified (byte-identical dumps), and the security model is carefully constructed: unmeasured inputs (variables, authorized_keys, unverified volumes) are rejected for V-Programs, extra fields are forbidden everywhere, and the SNP policy validation correctly handles Python's arbitrary-precision integers (negatives, unsigned 64-bit range, reserved bit 17). The int() coercion in validate_snp_policy correctly handles (int, Enum) members. The fixture item_hash matches the PR description claim exactly. The check_content validator pattern is consistent with the existing ProgramMessage. The only findings are minor test-coverage gaps (explicit mode='sev' and positive attestation_port in SNP mode are untested) that do not affect correctness.

aleph_message/models/execution/environment.py (line 266): The schema allows mode="sev" (explicit legacy), but there is no test covering this form. Note that mode="sev" is not wire-equivalent to mode=None for dumps: model_dump(exclude_none=True) includes mode="sev" (since "sev" is not None), so a round-trip dump would add the key. Consider adding a test documenting this behavior, or restrict the Literal to just "sev_snp" if explicit "sev" is not intended to be used on the wire.

aleph_message/models/execution/environment.py (line 279): attestation_port is tested only for the SEV-mode rejection (test line 361). There is no positive test verifying attestation_port can be set in sev_snp mode and round-trips correctly. A small test would close the gap.

[foxpatch-aleph]

Well-designed and correctly implemented PR adding the V-PROGRAM message type and SEV-SNP TEE mode. All tests pass, wire stability is verified, and the security model is thorough. No bugs or security vulnerabilities found. A few minor observations: the inherited metadata field is accepted in V-Programs but not explicitly addressed in the unmeasured-input rejection logic; check_content is a verbatim copy of ProgramMessage.check_content (consistent with existing patterns but a DRY concern); and there are minor test coverage gaps for attestation_port acceptance in SNP TEE mode and explicit mode='sev'.

aleph_message/models/execution/vprogram.py (line 192): The check_no_unmeasured_inputs validator rejects variables and authorized_keys as unmeasured host-to-guest input channels, but the inherited metadata field (from BaseExecutableContent) is also accepted and not rejected. If metadata reaches the guest VM as configuration or environment data, it would similarly be an unmeasured input channel bypassing the verity-bound workload contract. If metadata is purely node-side bookkeeping (scheduler tags, display info), this is fine — but the design doc or a comment should clarify that metadata does not reach the guest, or the validator should reject it for consistency with the "every input is measured or verity-bound" principle stated in the class docstring.

aleph_message/models/__init__.py (line 415): The check_content field validator on VerifiableProgramMessage is a verbatim copy of ProgramMessage.check_content (verified identical source). This is a DRY violation, but it's consistent with the existing codebase pattern where InstanceMessage lacks check_content entirely. Consider extracting this into a shared mixin or helper if more inline-capable message types are expected in the future.

aleph_message/tests/test_vprogram.py (line 368): Test coverage gap: attestation_port is tested only for rejection in SEV mode (line 372), but there is no test verifying it is accepted in SNP mode on TrustedExecutionEnvironment. Adding a positive test case would close this gap.

aleph_message/tests/test_vprogram.py (line 315): Test coverage gap: there is no test for explicit mode='sev' on TrustedExecutionEnvironment. The docstring says mode can be None or "sev" for legacy, but only mode=None is tested. Note that mode='sev' produces a different wire format than mode=None (it includes "mode": "sev" in model_dump(exclude_none=True)), which may be worth documenting or testing.