On NVIDIA's proprietary driver, function arrays that live in local memory
and are read under a data-dependent branch return wrong values in
subgroups 1-3 of a mesh workgroup; subgroup 0 is correct. A wave64
geometry program whose relative addressing keeps its VGPRs in the vector
window therefore loses register writes in every wave but the first. In
the clipping geometry program of Sony's PS5 PSP emulator (PPSA07550) the
empty waves never cleared their candidate primitive slots and wrote
degenerate triangles over wave 0's, so the 3D menu drew spikes.
On that driver a mesh program's window now lives in a device-local
storage buffer of 256 workgroup slots of 65536 dwords, claimed through a
per-slot lock and released after the final barrier. The pool is created
before the first draw that uses it records anything, and its header is
zeroed in a batch of its own that is submitted and waited for; the pool
is published only after that wait, and a failure releases it. Direct
register accesses keep one function variable per register; a direct
store also writes the buffer when a buffer read can see it, relative
reads load the buffer, relative writes store only to it, and a direct
read that may follow a relative write loads the buffer and refreshes the
variable. A buffer entry is zeroed only when a buffer read can see it
before a write. APS5_NO_MESH_WINDOW_BUFFER=1 keeps the arrays.
A DWARF-mode index entry with no usable FDE, encoding 0, an unknown
personality, and a mode-3 immediate outside the function now fail the
unwind. A Linux test walks a synthetic __unwind_info blob.
Co-authored-by: devindevsec <[email protected]>
On Windows, mmap sent a shared memory descriptor straight to the shared
file mapper, skipping the checks and the private path that a regular
file descriptor takes. A private mapping of a named or anonymous object
then failed with EOPNOTSUPP, and a writable shared mapping of a
read-only descriptor failed with EIO instead of EACCES. Shared memory
objects are files on Windows, so they now take the same access checks
and the same private copy as a regular file; only the directory, device
and file-type refusals stay limited to other descriptors.
guest_named_shm_windows_mapping covers shared mappings through two
descriptors, pread and pwrite against them, an offset mapping, a private
mapping, read-only mappings and the mappings after shm_unlink.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
EVO Player and Prospero Win measured RESOURCE_BUSY on ports opened on
bus type 0. The overlay bus is unmeasured, so its on-screen set is
still released as before, which video_out_flip_overlay relies on.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The console answers RESOURCE_BUSY (0x80290009) when the set holding
the buffer on screen is unregistered, and the set stays registered:
EVO Player measured it with a re-registration then failing
SLOT_OCCUPIED, and Prospero Win on firmware 12.02 after its flips went
idle. The set was released and 0 returned instead.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
PS5_PayloadSDK measured in a title (firmware 12.09) that
pthread_getaffinity_np answers sets of 8 and 16 bytes and returns ERANGE
for 32 bytes or more, so FreeBSD's 32-byte cpuset_t is refused. The call
accepted exactly 32 bytes and refused every other size. Sizes under 8
keep ERANGE; 17 to 31 bytes, between the measured sizes, throw.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Return the main program's handle, the first one sceKernelGetModuleList
lists and one sceKernelGetModuleInfo accepts. reSOT (PPSA99023) imports
it from libkernel and passes the handle to sceKernelGetModuleInfo to find
its own code segment; before this its eboot failed to load on the
unresolved import.
The PS5 3.20 export lists have it in libkernel as well as libkernel_sys,
and on Windows a libkernel import never reaches libkernel_sys, so the
throwing libkernel_sys stub moves to libkernel as pselect did.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The offline PS4 probe from #9797, built with SDK version 0x05050001, answers
sceNpWebApiCreateRequest with method 99 with INVALID_ARGUMENT (0x80552902) on
firmware 10.71, where the earlier build with a non-retail SDK version
accepted it. The debt entry now says the SDK 2.50 rule holds at that
version and that the version where it starts is not measured.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The ten operators allocate an object behind a 16-byte header that keeps its
allocator and free it through that allocator, as libSceNpCommon.sprx of
firmware 13.60 does (read from disassembly, not measured on a console). Five
were NotImplemented stubs; the other five were not exported.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Dean