Files
chimera-gfx-Public/docs/retroarch/phase-1.0d-loader-static-model.md
Chimera GFX release export a6037502d7
phase0-ci / build-and-audit (push) Successful in 2m14s
Publish Chimera GFX source
2026-09-03 03:27:14 +02:00

2.0 KiB

Phase 1.0D hardened-elfldr static model

The host-only model is in the separate chimera-retroarch fork at tools/ps5_elfldr_model.py. Its authority is elfldr.c at commit 197623058f509eddde18868dafcb92fdcac66464, file SHA-256 9949f8e4037984d10f1f5aa498e4665593d1fac8a33614d7f2141349839bb803.

It reproduces source checks and data operations for the initial size/magic and program-file bounds, ET_DYN/ET_EXEC, mapping range, PT_LOAD copies, relative relocations, protection layout, entry mapping, synthetic saved RIP, RSP, RDI, and 16 KiB argument-resource mapping. It inventories DT_NEEDED and undefined symbols but correctly records that SDK startup—not elfldr_load—resolves them.

The source does not validate several expected ELF properties: class, data encoding, machine, header entry sizes, segment overlap/alignment, and mapped entrypoint are not loader rejection conditions. The model reports these as source-validation gaps. It never invents stricter acceptance rules.

Input SHA-256 Result
Phase-1.0B smoke 16c04afe26c490b5071388dc9a32524d09d50d181b1baffbbc54bd96f0c2c688 ACCEPTED_BY_STATIC_MODEL
CRT canary c84c0fb43392ce17abc1e7e6be38b522f1b32a681fd516d684c3dbbf7b34b743 ACCEPTED_BY_STATIC_MODEL
early diagnostic 092bcabc0f8717a648030c592aa0dc900f878952fb14ee453851a29f298ea7ee ACCEPTED_BY_STATIC_MODEL
lifecycle reference bfb4a5cc768e162fe4c2fddf41c3978e152722918a39085277fd172cb95a7182 ACCEPTED_BY_STATIC_MODEL

Negative host copies prove deterministic rejection for bad magic, unsupported type, and out-of-file segment ranges. An unmapped entry yields MODEL_INCOMPLETE, while a wrong machine remains accepted with an explicit source-validation gap because the actual loader does not check it.

ACCEPTED_BY_STATIC_MODEL means only “no deterministic rejection in the modeled source path.” It is not proof of runtime allocation, kernel calls, imports, firmware behavior, receipt, entry, execution, notification, cleanup, or return.