Publish Chimera GFX source

docs/runtime/phase-0.9-anti-brick-threat-model.md

@@ -0,0 +1,188 @@
+# Phase 0.9A offline anti-brick threat model
+
+Status: **DESIGN_ONLY**. Historical operational status:
+**READ_ONLY_PREFLIGHT_BLOCKED**.
+
+This is an offline design review. It does not describe a proven PS5
+filesystem, installation method, recovery method, path, syscall or switch
+primitive. No PS5 was contacted; no file was transferred, installed or
+executed; no target artifact was created. Host simulation is not hardware
+evidence.
+
+## Evidence boundary
+
+The review uses only existing repository evidence:
+
+- immutable Phase-0.8 record and Phase-0.8R remediation contract;
+- the permanent artifact denylist;
+- Phase-0.7 offline identities for the hardened elfldr and controlled Payload
+  Manager candidates;
+- stock elfldr and Payload Manager sizes and hashes as `reference_only`;
+- the offline rollback and installation review documents;
+- clean local source identities for hardened elfldr, controlled Payload
+  Manager and the unchanged lifecycle-probe source.
+
+Current on-device paths, mounts, object IDs, hashes, firmware behavior,
+processes, services, listeners, autoload state, backups and recovery paths
+remain unobserved. The byte-exact on-device Payload Manager backup remains a
+hard STOP gate.
+
+Severity means:
+
+- `CATASTROPHIC`: can remove the only working launch/recovery path, destroy
+  both live and rollback identities, run unverified code automatically, or
+  make recovery depend on a failed component;
+- `HIGH`: can select or persist wrong/partial bytes, invalidate the evidence
+  binding, or prevent controlled recovery;
+- `MEDIUM`: disrupts control or observation but does not alone prove loss of
+  both live and recovery objects;
+- `LOW`: occurs before live mutation and should leave the old object intact,
+  but still needs platform evidence.
+
+## Control profiles
+
+### A — wrong target
+
+Possible damage is replacement of an unrelated or critical object. Before any
+future mutation, one no-follow stable object must bind literal path, mount ID,
+object ID, type, size and SHA-256, and the identity must be repeated
+immediately before mutation. AB-001, AB-003, AB-004 and AB-007 prevent the
+write. Recovery would require a separate verified backup and independent
+executor; neither is proven. Namespace and object-identity semantics remain
+`UNPROVEN`, so Phase 0.9A blocks.
+
+| ID | Scenario | Severity |
+|---|---|---|
+| TM-A-01 | wrong path | CATASTROPHIC |
+| TM-A-02 | wrong mountpoint | CATASTROPHIC |
+| TM-A-03 | symlink, junction or other redirect | CATASTROPHIC |
+| TM-A-04 | path resolves to another object after preflight | CATASTROPHIC |
+| TM-A-05 | case or path normalization changes identity | HIGH |
+| TM-A-06 | target is replaced between check and write | CATASTROPHIC |
+
+### B — wrong pre-image
+
+Possible damage is treating modified or firmware-incompatible bytes as stock.
+The future evidence must bind firmware, manifest, stable object, size and
+digest in one current observation. AB-001 through AB-004 reject every partial
+match. Detection must happen before mutation; rollback is not a substitute.
+Current device identities and firmware runtime behavior remain `UNPROVEN`.
+
+| ID | Scenario | Severity |
+|---|---|---|
+| TM-B-01 | live hash differs from stock reference | HIGH |
+| TM-B-02 | live size differs | HIGH |
+| TM-B-03 | object ID changes | CATASTROPHIC |
+| TM-B-04 | firmware differs | HIGH |
+| TM-B-05 | manifest belongs to another build | HIGH |
+| TM-B-06 | modified installation is treated as stock | CATASTROPHIC |
+
+### C — backup failure
+
+Possible damage is loss of all trusted rollback bytes. A backup must be
+created before staging, on a separate identity, then closed, reopened,
+re-identified and rehashed. Capacity, mapping and an independent recovery
+executor must be proven. AB-005, AB-006, AB-016 and AB-017 block mutation
+until this holds. The Payload Manager backup is currently a
+`CATASTROPHIC` hard blocker.
+
+| ID | Scenario | Severity |
+|---|---|---|
+| TM-C-01 | backup missing | CATASTROPHIC |
+| TM-C-02 | backup is the same object as live | CATASTROPHIC |
+| TM-C-03 | backup is on the same vulnerable path | CATASTROPHIC |
+| TM-C-04 | backup is partial | CATASTROPHIC |
+| TM-C-05 | backup hash differs | CATASTROPHIC |
+| TM-C-06 | backup cannot be reopened | HIGH |
+| TM-C-07 | backup-to-target mapping is ambiguous | CATASTROPHIC |
+| TM-C-08 | recovery tool depends on the replaced component | CATASTROPHIC |
+| TM-C-09 | storage or metadata capacity is insufficient | HIGH |
+| TM-C-10 | backup is created only after live mutation | CATASTROPHIC |
+
+### D — write and power loss
+
+Possible damage is a missing, partial or ambiguous live identity. A safe design
+needs isolated staging, durable files and directory metadata, and one
+old-or-new atomic switch. AB-007 through AB-013 reject in-place overwrite and
+unproven switch semantics. No such PS5 primitive is proven.
+
+| ID | Scenario | Severity |
+|---|---|---|
+| TM-D-01 | power loss before staging | LOW |
+| TM-D-02 | power loss during staging | HIGH |
+| TM-D-03 | power loss after staging before verification | HIGH |
+| TM-D-04 | power loss during live switch | CATASTROPHIC |
+| TM-D-05 | power loss immediately after live switch | CATASTROPHIC |
+| TM-D-06 | power loss before directory metadata is durable | CATASTROPHIC |
+| TM-D-07 | partial write | CATASTROPHIC |
+| TM-D-08 | short write | HIGH |
+| TM-D-09 | write error | HIGH |
+| TM-D-10 | flush or fsync error | CATASTROPHIC |
+| TM-D-11 | file bytes correct but directory not durable | CATASTROPHIC |
+| TM-D-12 | new file has wrong ownership, mode or metadata | HIGH |
+
+### E — process and lifecycle
+
+Possible damage is automatic launch of unverified bytes, stale mappings or a
+crash loop. A future observation must establish all relevant owners,
+instances, mappings, listeners, supervisors and authoritative autoload/retry
+state. AB-010, AB-013, AB-014 and AB-020 require quiescence and a later
+one-shot approval. Unknown topology blocks before switch.
+
+| ID | Scenario | Severity |
+|---|---|---|
+| TM-E-01 | target executable is active | HIGH |
+| TM-E-02 | multiple instances exist | HIGH |
+| TM-E-03 | service restarts itself | CATASTROPHIC |
+| TM-E-04 | listener conflict | MEDIUM |
+| TM-E-05 | process holds old file or mappings | HIGH |
+| TM-E-06 | watchdog or supervisor automatically restarts | CATASTROPHIC |
+| TM-E-07 | autoload starts the candidate before verification | CATASTROPHIC |
+| TM-E-08 | automatic retry creates a crash loop | CATASTROPHIC |
+
+### F — rollback failure
+
+Possible damage is restoring wrong bytes to a wrong path, automatic execution
+or loss of the recovery executor. Rollback must bind the preverified backup,
+exact target mapping and independent executor. AB-006 and AB-015 through
+AB-017 require a separate approval and post-rollback identity proof. A failed
+rollback verification is `CATASTROPHIC/BLOCKED`, never a retry.
+
+| ID | Scenario | Severity |
+|---|---|---|
+| TM-F-01 | wrong backup selected | CATASTROPHIC |
+| TM-F-02 | wrong rollback target path | CATASTROPHIC |
+| TM-F-03 | rollback interrupted | CATASTROPHIC |
+| TM-F-04 | restored hash is wrong | CATASTROPHIC |
+| TM-F-05 | rollback automatically starts a service | CATASTROPHIC |
+| TM-F-06 | rollback works only if Payload Manager works | CATASTROPHIC |
+| TM-F-07 | rollback works only if elfldr works | CATASTROPHIC |
+
+### G — operator error
+
+Possible damage is a role swap, reused authority or combined loss of both
+runtime components. Component manifests and approvals must be bound to one
+device, firmware, action, hash, size and expiration. AB-018 through AB-020
+prohibit a combined transaction, exclude the lifecycle probe and stop phase
+carryover. Component order is not guessed.
+
+| ID | Scenario | Severity |
+|---|---|---|
+| TM-G-01 | hardened elfldr and Payload Manager are swapped | CATASTROPHIC |
+| TM-G-02 | lifecycle probe is treated as installation candidate | CATASTROPHIC |
+| TM-G-03 | wrong firmware or build is selected | HIGH |
+| TM-G-04 | two installation phases are combined | CATASTROPHIC |
+| TM-G-05 | approval for one component is reused for another | HIGH |
+| TM-G-06 | stale manifest is used | HIGH |
+| TM-G-07 | general READY overrides a specific blocker | CATASTROPHIC |
+
+The item-specific reasons and machine bindings are in
+`manifests/runtime/phase-0.9-anti-brick-design.json`.
+
+## Decision
+
+Every threat is detectable only under evidence contracts that are not yet
+satisfied on the PS5. The design is fail-closed and suitable for host review,
+but not for installation engineering on a device.
+
+**BLOCKER: NO PROVEN POWER-LOSS-SAFE SWITCH.**