A resumed console does not necessarily put every CPU core back behind the same memory boundary at the same instant. That is what makes the PS5 S3 (suspend-to-RAM) AP-startup bug interesting: reopening a one-shot operation can be dangerous when the cores it starts are still in a more privileged memory view.
soniciso1's S3-resume writeup describes a boundary crossing from an already-compromised GameOS kernel into hypervisor memory. The useful lesson is about when protection becomes active, not merely whether a launch operation has already been used.
Two page-table layers, different jobs
The guest's CR3 selects its own page tables. Nested page tables (NPT), controlled by the hypervisor, provide a second translation layer that restricts which physical memory the guest can reach. Controlling guest page tables should not, by itself, expose hypervisor RAM.
In the writeup's terminology, NPT root 0 is the host view, including hypervisor memory; root 1 is the restricted GameOS view. The choice is per core. The BSP is the bootstrap processor that resumes first; APs are the other processors waiting to be started.
That distinction matters: “the BSP is back in the guest view” does not mean every parked AP is too.
How three resume decisions compose
The described sequence is:
- Resume resets startup state. S3 reinitialization clears the one-shot AP-startup bitmap and initializes per-core NPT selection to root 0.
- The BSP becomes restricted first. Its first GameOS kernel-text fetch switches it to root 1. Parked APs have not made that fetch, so remain at root 0.
- GameOS can still request an AP launch. The
khv_startup_mphypercall accepts a core, entry address and guest page-table root. Its one-shot bookkeeping limits repeated launches, but does not authenticate a hypervisor-owned resume phase.
A compromised kernel can therefore select an AP entry point that avoids the kernel-text fetch responsible for switching that core's NPT. In the author's account, guest-selected code runs while the AP still has the host memory view.
The launch bit answers “has this AP already been started?” It does not answer “is this caller allowed to start it now, and under which memory boundary?”
What the reported proof establishes
The writeup reports a 10.00 hardware proof that located all sixteen live GameOS VMCBs—the control structures for guest execution—and performed a write/read-back/restore on a reserved field in each. It explicitly left the active nested-paging controls untouched.
That is a reported memory-write demonstration, not a demonstration that those active controls were changed. The writeup's 13.60 assessment is static analysis, not proof that the original 10.00 binary works there. Prior kernel read/write and ROP or kernel-call capability are prerequisites; this is not an unprivileged entry point.
Put the boundary before the hand-off
The strongest invariant in the proposed remediation is straightforward: an AP must have its final guest NPT before it executes any guest-selected instruction. Do not rely on that instruction stream eventually taking a path that restricts itself.
The author also proposes binding startup to an authenticated resume phase and constraining the entry point and page-table root. These are proposed fixes, not a claim that a released firmware implements them.
For a design that genuinely needs to restart APs after suspend, would you retain a guest-callable startup interface with a narrowly authenticated resume phase, or move AP restart entirely under hypervisor control? What state would you require to be established before the first guest instruction?