Files
chimera-gfx-Public/docs/retroarch/phase-1.0c-device-smoke-result.md
T
Chimera GFX release export fee37cd9b5
phase0-ci / build-and-audit (push) Failing after 1m41s
Publish Chimera GFX source
2026-09-03 02:53:36 +02:00

154 lines
6.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Phase 1.0C PS5 device smoke result
Date: 2026-07-19
Local window: 16:1916:31 CEST
Classification: `DEVICE_SMOKE_PARTIAL`
## Result
The exact Phase-1.0B candidate was rebuilt, reopened, and verified before
device contact:
- artifact: `retroarch_ps5_software_smoke.elf`;
- size: 1,826,216 bytes;
- SHA-256:
`16c04afe26c490b5071388dc9a32524d09d50d181b1baffbbc54bd96f0c2c688`;
- linker-map SHA-256:
`21dfdaa44261f8d546fa9ea71102162dc880a8ca8037526019a04fece5b21313`;
- Phase-1.0B build-manifest SHA-256:
`8ee4305bc2d7e5d75d3f7a4b0b335de39c68932ca49c199310cda9f2279dd69f`.
The complete offline preflight passed: both repositories and pinned upstreams
were clean and exact, the clean target rebuild reproduced the authorized
identity, the artifact remained stable across reopen and rehash, all 30
Chimera GFX CTest cases passed, all 26 Phase-1.0B Python guardrails passed,
and the RetroArch host smoke, fault, sanitizer, import, relocation, segment,
exit-path, and persistent-write checks passed.
No Phase-1.0C target, sender, installation, autoload, or device-management
code was created.
## Authorization and attempts
The operator confirmed all twelve device-preflight statements immediately
before the first connection. The first artifact-specific authorization
permitted one connection, transfer, execution attempt, and 75-second
observation. That transfer completed locally, but the operator's display was
off, so no screen evidence was obtained. The operator reported that the
console had not hung and still functioned normally.
The operator then explicitly overrode the no-later-action boundary and issued
a new manual authorization for one additional run of the same hash-bound
artifact to the same session address. This was a separately initiated manual
action, not an automatic retry. The artifact and sender were reopened and
rehashed before the second connection. The second transfer also completed
locally. During the second 75-second window the operator observed no visible
change and reported that the console continued to respond normally.
| Counter | Result |
|---|---:|
| TCP connections opened by the selected sender | 2 |
| complete local `sendall` operations | 2 |
| bytes offered per operation | 1,826,216 |
| loader execution attempts requested | 2 |
| executions independently observed | 0 |
| automatic retries | 0 |
| further attempts | 0 |
The second action is recorded because it occurred, but it does not retroactively
change the scope of the first authorization. No third attempt is authorized or
performed.
## Transport evidence
The selected client was the existing official Y2JB source-controlled sender:
- source:
`Gezine/Y2JB@0dbbf4e7e0203af7e5d101a3256c634edf4e3ba2:payload_sender.py`;
- sender SHA-256:
`8c87920c41dbdbd66b9f36ca9509f0d6bef9170f351dd97ff831cfb98e642ec6`;
- transport: one IPv4 TCP connection per invocation, explicit port 9021;
- local input: binary read of the selected ELF;
- send behavior: CPython `sendall`, which completes all local sends or raises;
- retry/resume: absent;
- response/acknowledgement: absent;
- close: after successful `sendall`.
The audited hardened elfldr source at
`197623058f509eddde18868dafcb92fdcac66464` recognizes raw ELF magic, receives
the complete ELF extent into memory, and makes one spawn attempt without
filesystem staging, installation, rename, deletion, or live-file replacement.
That local source identity is transport evidence, not byte-exact proof of the
currently running device listener.
Both sender invocations exited successfully and reported 1,826,216 locally
sent bytes. Because the raw route has no peer acknowledgement, remote receipt,
parse completion, child creation, entry, and exit are not independently proven.
## Device observations
| Observation | Result |
|---|---|
| anonymized device ID | `PS5-FW960-SESSION-A` |
| firmware source | operator confirmation from PS5 UI |
| raw firmware value | `9.60` |
| first visible phase | `UNOBSERVED` |
| last visible phase | `UNOBSERVED` |
| first error code | `UNOBSERVED` |
| write-firewall status | `UNOBSERVED` |
| video/title/frame/flip | no visible change observed |
| controller/digital/sticks | not observed |
| audio/submits | not observed |
| Options shutdown | not observed |
| automatic deadline | not observed |
| process exit | not observed |
| host observation windows | 75,235 ms and 75,405 ms |
| console response after attempts | normal according to operator |
| jailbreak/elfldr session | not independently tested after the attempts |
| reboot needed | no |
| unexpected persistent effect | none reported; not independently inspected |
| photo/video evidence | none |
The first window supplied no visual evidence because the display was off. The
second window supplied a direct negative observation: no visible change
occurred while the console remained responsive.
## Classification and remaining risk
This result is `DEVICE_SMOKE_PARTIAL`, specifically:
`NO_VISIBLE_OUTPUT; REMOTE_EXECUTION_AND_ENTRY_UNCONFIRMED; CONSOLE_RESPONSIVE`
It is not a pass. The evidence does not prove `S00`, `S07`, any error code,
VideoOut, Pad, AudioOut, the runtime deadline, teardown, or `_Exit`. It is not
a session-recoverable failure because no crash, hang, lost session, or reboot
need was observed. It is not a transfer failure because both host-side
`sendall` operations completed, although the protocol cannot attest peer
receipt or execution.
The remaining focused questions are:
1. whether the deployed port-9021 listener is byte-equivalent to the audited
hardened source;
2. whether it accepted and parsed the complete ELF;
3. whether child creation or `_start` failed before the first visible frame;
4. whether VideoOut initialization failed without a visible reporting path;
5. whether the process ran and exited before the display showed a frame.
No installation, autoload change, persistent staging, Payload Manager request,
live-file replacement, delete, cleanup write, automatic retry, or reboot
command was performed.
## Next phase
The exact proposed next implementation phase is:
`PHASE 1.0D — OFFLINE LOADER-TO-ENTRY AND EARLIEST-VISIBLE-ERROR DIAGNOSIS`
It must remain host/offline work until separately reviewed. It should focus
only on distinguishing loader receipt, child entry, and pre-first-frame
VideoOut failure using already public, bounded userland contracts. It must not
introduce installation, autoload, dynamic cores, GNM, or another device run.