M1 x86-64 Reference Partition

Objective

The first real point of the portable-partition-semantics comparison: the same conceptual flight partition, realized end-to-end on x86-64.

Partition Contract
        ↓
IR
        ↓
Xen
        ↓
RTEMS / Linux

Scope

  • Contract parser

  • contract validator (against schemas/partition-contract.schema.json semantics)

  • capability manifest check: every capabilities_required tag is either covered by the backend manifest (compile), covered with a waiver recorded in the evidence graph (compile, exception), or absent (build fails), no silent semantic downgrade

  • IR implementation (IR v1)

  • Xen backend for x86-64

  • boot / deployment of partitions

  • basic partition monitoring

This milestone makes x86-64 the CI / reproducibility platform of the project. Guard independence runs at Stage 0 (co-resident software Guard) throughout M1-M3; no common-mode independence claim is made at these stages.

Deliverables

  • parser + validator (contract → IR)

  • IR v1 implementation (behaving per [architecture/ir] (../architecture/ir))

  • Xen backend implementing [architecture/backend-model] (../architecture/backend-model)

  • boot/deployment for the reference partition

  • basic monitoring (partition state visible to a watchdog-style recovery hook)

Tests

  • reproducible boot

  • CPU allocation

  • memory isolation

  • communication (declared endpoints only)

  • basic fault containment

Acceptance gate

x86-64 reference boots and isolates partitions.

Current status

Planned (after M0 sign-off).

Known limitations

  • x86-64 evidence is mechanism evidence, it does not transfer to flight hardware (re-stated on every M3+ cross-target comparison page).

  • “Basic fault containment” is a starting capability; the full fault class matrix and recovery timing model come in M3/M5.

  • The Xen backend is the realization; no contract or IR change may depend on Xen-specific concepts (ADR-0003 is enforced in review).