AMD PSP reverse engineering, emulator and vulnerability research https://git.sl0p.foo/amd-psp-re.git/atom/hw/ring_create_fuzz.py?h=main 2026-09-30T02:06:09Z 2026-09-30T02:06:09Z user user@clank 2026-09-30T02:06:09Z urn:sha1:8fc966e4d43af8322a293386b84298f0defe8bfc The last host-to-processor surface is the ring-creation registers, whose status field reports acceptance directly so nothing need be inferred. That validation layer is good: zero, one and all-ones sizes are rejected with one code, a two-gigabyte size with another, and a base inside the trusted region with a third, so the trusted region is explicitly excluded from the ring base. The gap is alignment. A base one byte off is accepted at creation and the processor then dies on the first submit. The aligned control runs first in the same boot and succeeds with the heartbeat advancing, so this is not an inherited dead processor, the failure mode that produced phantom hits twice in this audit. It is an inconsistency rather than a policy, since command-buffer and image misalignment are both rejected with their own codes, and the consequence is deferred to first use in the same shape as an earlier zero-length descriptor defect. It is an eighth denial-of-service trigger, not corruption. A process note is kept: the first sweep reported every case including the control as wedged, caused by a syntax error in the script so that nothing ran, and the control is what exposed it.