107 lines
4.4 KiB
Markdown
107 lines
4.4 KiB
Markdown
# Phase 0.9A recovery and rollback contract
|
|
|
|
Status: **DESIGN_ONLY — RECOVERY UNPROVEN**.
|
|
|
|
This contract states what future evidence must prove. It does not authorize or
|
|
implement backup creation, transfer, installation, switch, rollback or
|
|
execution.
|
|
|
|
## Valid backup contract
|
|
|
|
A future backup is valid only when all conditions hold:
|
|
|
|
1. it is created before staging or any live mutation;
|
|
2. the source object and exact restoration target are recorded;
|
|
3. the source stays the same stable object throughout the read;
|
|
4. every byte is read and the exact size is recorded;
|
|
5. SHA-256 equals the current observed pre-image;
|
|
6. the backup is a distinct object, not an alias of live;
|
|
7. it is closed, reopened without redirection, re-identified and rehashed;
|
|
8. its storage medium and mount are recorded;
|
|
9. content and metadata capacity plus reserve are proven;
|
|
10. autoload, cleanup and packaging cannot delete it;
|
|
11. it is never replaced by candidate bytes;
|
|
12. mapping is literal and not selected by a glob, basename or guess;
|
|
13. rollback does not guess the live target;
|
|
14. recovery can use it without the component being replaced.
|
|
|
|
A second byte-exact off-device copy with its own manifest and SHA-256 is
|
|
strongly recommended. Creating or transferring that copy is a later,
|
|
separately authorized phase and is not permitted here.
|
|
|
|
For the controlled Payload Manager, an absent, differing, unstable,
|
|
non-reopenable or recovery-dependent byte-exact on-device backup remains a
|
|
**HARD STOP-GATE**.
|
|
|
|
## Recovery independence
|
|
|
|
Before any component transaction, evidence must answer all rows without
|
|
inference:
|
|
|
|
| Question | Hardened elfldr | Controlled Payload Manager |
|
|
|---|---|---|
|
|
| How is recovery started? | UNPROVEN | UNPROVEN |
|
|
| Which exact component executes recovery? | UNPROVEN | UNPROVEN |
|
|
| Is that executor outside the component being replaced? | UNPROVEN | UNPROVEN |
|
|
| Does recovery work when elfldr does not start? | UNPROVEN | UNPROVEN |
|
|
| Does recovery work when Payload Manager does not start? | UNPROVEN | UNPROVEN |
|
|
| Does recovery work without autoload? | UNPROVEN | UNPROVEN |
|
|
| Does recovery work without the replaced listener? | UNPROVEN | UNPROVEN |
|
|
| Is a second independent recovery path proven? | UNPROVEN | UNPROVEN |
|
|
|
|
A generic console recovery mode is not counted. No public evidence in this
|
|
repository proves that it restores custom project files.
|
|
|
|
If rollback depends on the component being replaced, the result is:
|
|
|
|
**CATASTROPHIC BLOCKER.**
|
|
|
|
## Rollback transition
|
|
|
|
Rollback is not an automatic exception path. It requires:
|
|
|
|
```text
|
|
POST_SWITCH_VERIFY failure
|
|
-> ROLLBACK_REQUIRED
|
|
-> separate human ROLLBACK_AUTHORIZED
|
|
-> ROLLBACK_IN_PROGRESS
|
|
-> ROLLBACK_VERIFIED
|
|
```
|
|
|
|
The rollback action may use only the already reopened and verified backup and
|
|
the fixed target mapping. It may not autoload, start or retry either component.
|
|
After the switch, path, mount, object ID, type, size, SHA-256, ownership, mode
|
|
and relevant metadata are re-established before any later decision.
|
|
|
|
An interrupted rollback is acceptable only if a proven atomic primitive leaves
|
|
exactly one complete live identity and preserves the verified backup. That
|
|
primitive is not proven on PS5. A wrong post-rollback hash is
|
|
`CATASTROPHIC/BLOCKED`; there is no retry.
|
|
|
|
## Component isolation
|
|
|
|
The hardened elfldr and controlled Payload Manager have separate live
|
|
pre-images, backups, candidates, target mappings, recovery dependencies,
|
|
process/service/listener states, autoload evidence, approvals, staging,
|
|
switches, post-switch checks, executions, acceptances and rollbacks.
|
|
|
|
There is no shared approval and no combined transaction. A second component
|
|
cannot begin until the first is separately accepted or fully rolled back.
|
|
Which component comes first is `UNPROVEN`; order must follow demonstrated
|
|
dependencies rather than convenience. The lifecycle probe is outside both
|
|
installation and rollback models.
|
|
|
|
## Current blockers
|
|
|
|
- historical `READ_ONLY_PREFLIGHT_BLOCKED`;
|
|
- current live identities and firmware behavior are unproven;
|
|
- exact Payload Manager backup is absent as proven evidence;
|
|
- filesystem atomicity, exchange, file durability and directory durability are
|
|
unproven;
|
|
- process, supervisor, listener, autoload and retry topology is unproven;
|
|
- no independent recovery executor or second recovery path is proven;
|
|
- no component order is proven;
|
|
- every device authorization remains false.
|
|
|
|
No blocker is lifted by this design, manifest, host simulator or test result.
|