feat(macan/sm8845): guard mode-1 KM device-state RPMB persist + fix mode-2 SPSS-absent#51
feat(macan/sm8845): guard mode-1 KM device-state RPMB persist + fix mode-2 SPSS-absent#511vivy wants to merge 7 commits into
Conversation
…ode-2 SPSS-absent Add support for macan / sm8845 (OnePlus 15R ≈ OnePlus Ace 6T). The mode-0 diag bundle labelled "Ace 6T / canoe / sm8850" is, by hard ABL/partition evidence (`OPLUS SM8845 Attestation`, ro.board.platform=sm8845, ro.product.device=macan), actually macan/sm8845 — a different SoC from canoe(sm8850). mode-0 already boots cleanly on it (detect_oem maps oneplus→oplus); this PR closes two sm8845-specific gaps. 1. mode-1 RPMB lock-state brick (the reported failure). macan persists KeyMaster device-state to RPMB via an OEM-added KM command WRITE_KM_DEVICE_STATE (cmd 0x203, KEYMASTER_UTILS+3) that is absent from the open QcomModulePkg BSP — the BSP RoT/boot-state path (SET_ROT 0x201 + SET_BOOT_STATE 0x208) never persists, so 0x203 is the sole RPMB commit (logfs shows it bracketed by `VB: RWDeviceState: Succeed using rpmb!`). The pre-existing fakelock suppressed three RPMB lock paths (VB WRITE_CONFIG, VB reset, OplusSec 0x0A); 0x203 was the unguarded fourth. Under mode-1 the ABL believes it is locked and commits a locked RoT to RPMB, which then disagrees with the real bootloader after revert-to-stock — the brick a user hit. FakelockOverlay_ShouldDropKmDeviceStateWrite now swallows 0x203 under WantFakelockHook, gated to the keymaster TA handle in QseecomHook (handle pinned lazily from the first 0x200–0x2FF cmd because keymaster preloads via LoadSecureApps before our StartApp hook). Fakelock stays ephemeral: still reports locked (0x201/0x208 RAM state) but never persists it. Universal under fakelock — no per-SoC gate, no-op where 0x203 isn't issued. 2. mode-2 SPSS-absent must not be fatal on sm8845. macan publishes no SPSS protocol (LocateProtocol → Not Found; SPU never comes up). This is the BSP's own "this chipset doesn't mirror keymint to SPU" path (ShareKeyMintInfoWithSPU returns success on NOT_FOUND) — there is no SPU enforcement domain to spoof, and the KM/QSEECOM ProfileOverlay is authoritative. InstallAll previously treated SPSS-fail as FATAL under WantProfileSpoof, so mode-2 would abort chain-load on macan. SpssHook now returns EFI_NOT_FOUND benignly and InstallAll special-cases it (expected=0, no abort); a real SPSS failure on an SPU chipset (canoe/infiniti) stays fatal under profile-spoof. Verified: EDK2 firmware build (-Werror) clean; tests/046 extended to lock in the 0x203 guard + keymaster-handle tracking + SPSS NOT_FOUND handling; 045/046/047 lint pass. Device identity, mechanism, and evidence recorded in docs/project/re-findings.md. Note: this prevents NEW bricks; it does not un-brick an RPMB that already holds a fake-locked state. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Adds macan/sm8845-specific robustness to protocol-hook overlays so mode-1 fakelock never persists a spoofed lock state to RPMB, and mode-2 profile-spoof no longer aborts on chipsets that legitimately lack SPSS/SPU mirroring.
Changes:
- Add a mode-1 fakelock guard that drops KeyMaster
WRITE_KM_DEVICE_STATE(0x203) writes (RPMB persistence path) gated to the KeyMaster TA handle. - Treat SPSS absence (
EFI_NOT_FOUND) as a benign capability gap (0 expected slots) so mode-2 doesn’t fail on no-SPU chipsets (e.g., sm8845). - Extend lint coverage + document findings and update user-facing mode description.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| tests/046_mode1_protocol_hook_lint.sh | Adds greps asserting the new KM device-state drop path and benign SPSS EFI_NOT_FOUND handling. |
| README.md | Documents mode-1 fakelock as ephemeral and enumerates the four suppressed RPMB lock-state paths, including KM 0x203. |
| GblChainloadPkg/Library/ProtocolHookLib/SpssHook.c | Returns EFI_NOT_FOUND when SPSS protocol is absent and logs a benign message. |
| GblChainloadPkg/Library/ProtocolHookLib/QseecomHook.c | Tracks KeyMaster TA handle and drops cmd 0x203 under mode-1 fakelock to prevent RPMB persistence. |
| GblChainloadPkg/Library/ProtocolHookLib/InstallAll.c | Special-cases SPSS EFI_NOT_FOUND as non-fatal (expected slots = 0), preserving fatal behavior for real SPSS failures under mode-2. |
| GblChainloadPkg/Library/ProtocolHookLib/FakelockOverlay.h | Exposes new overlay policy function for dropping KM device-state persist command. |
| GblChainloadPkg/Library/ProtocolHookLib/FakelockOverlay.c | Implements FakelockOverlay_ShouldDropKmDeviceStateWrite for KM cmd 0x203. |
| docs/project/re-findings.md | Records macan/sm8845 identity evidence and the two fixed failure mechanisms. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| Status = gBS->LocateProtocol (&gEfiSPSSProtocolGuid, NULL, (VOID **)&Spss); | ||
| if (EFI_ERROR (Status) || Spss == NULL) { | ||
| if (Status == EFI_NOT_FOUND || (Status == EFI_SUCCESS && Spss == NULL)) { |
There was a problem hiding this comment.
Agreed — fixed in 56dfe7d. Split the two cases: honest EFI_NOT_FOUND returns NOT_FOUND (benign "no SPU on this chipset"), while EFI_SUCCESS with a NULL interface (a published-handle contract violation) now returns EFI_DEVICE_ERROR so a corrupt handle is never mistaken for absent-capability.
The original write-up leaned on a spurious correlation — that macan's WRITE_KM_DEVICE_STATE (0x203) was "bracketed by VB: RWDeviceState rpmb!" lines. Those lines are the VerifiedBoot DeviceInfo path: they fill the project's validated infiniti mode-1 capture too, which issues 0x203 zero times. They are not evidence that 0x203 writes RPMB. Replace it with a controlled comparison against that infiniti mode-1 capture (logs/20260524-012314_manual_mode-1-v2.3.4-installed): KM cmd infiniti mode-1 (safe) macan mode-0 SET_ROT 0x201 7x 1x SET_BOOT_STATE 0x208 7x isUnlocked=0 1x isUnlocked=1 WRITE_KM_DEVICE_STATE 0x203 0x 2x Infiniti's validated, non-bricking mode-1 already drives a locked RoT/boot-state every boot but never issues 0x203 — the locked state is ephemeral. macan adds exactly that persistence command. Suppressing it under fakelock converges macan mode-1 onto infiniti's safe behavior, and is safe because infiniti's KM TA works with 0x203 never sent. Explicitly records what remains unproven: no macan mode-1 capture exists; 0x203 -> RPMB is inferred from the command name + the user report, not disassembly. No code behavior change — comment + docs + memory only. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f415a07e5e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (Status == EFI_NOT_FOUND) { | ||
| /* SPSS protocol genuinely absent on this chipset (sm8845/macan-class): the | ||
| ABL does not mirror KeyMaster state to an SPU, so there is no SPU | ||
| enforcement domain to spoof. This is NOT a failure even under | ||
| profile-spoof — the KeyMaster/QSEECOM overlay (ProfileOverlay_RewriteKmSend) | ||
| is authoritative on such chipsets. Expect 0 slots; do not abort. */ |
There was a problem hiding this comment.
When a profile-spoof build runs on an SPU-backed target such as canoe/infiniti and the SPSS DXE fails before publishing gEfiSPSSProtocolGuid, LocateProtocol returns the same EFI_NOT_FOUND handled here. This branch now marks SPSS as expected=0 and continues, so mode-2 can boot after rewriting only QSEECOM while leaving the SPU KeyMint mirror unhooked; that contradicts the required-hook behavior described above for chipsets that do publish SPSS. Please gate this benign path to the known no-SPU platform/capability, or keep EFI_NOT_FOUND fatal under WantProfileSpoof unless the platform is known to lack SPSS.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch — agreed, this was a real fail-open regression and is reverted in 56dfe7d. InstallAll keeps SPSS install fatal under WantProfileSpoof, including EFI_NOT_FOUND, exactly because that return is ambiguous (no-SPU SoC like macan vs. an SPU-backed canoe/infiniti whose SPSS DXE failed to publish this boot). Booting mode-2 with the SPU KeyMint mirror unhooked on a platform that has an SPU is the worse outcome, so we fail closed → FastbootLib. Enabling mode-2 on a known no-SPU SoC is deferred to a positive capability signal (a manifest flag the installer sets from ro.board.platform), not a blanket NOT_FOUND pass. The mode-0/mode-1 paths (which never set WantProfileSpoof) still continue observation-only, matching the macan mode-0 bundle (spss=0/1).
| if (FakelockOverlay_ShouldDropKmDeviceStateWrite (CmdId, &FakeStatus)) { | ||
| HookLeave (&gQseecomSendGuard); | ||
| return FakeStatus; | ||
| } |
There was a problem hiding this comment.
When fakelock drops WRITE_KM_DEVICE_STATE, this returns before gOriginalSendCmd without writing anything to RspBuf. The surrounding KeyMaster decoder already treats response word 0 as a TA status for this command family, so an ABL that checks both the QSEECOM transport status and the TA response can see stale/uninitialized response bytes and treat the synthetic success as a KM failure. Please synthesize the expected success response before returning, as well as EFI_SUCCESS.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Agreed — fixed in 56dfe7d. The 0x203 swallow now ZeroMems RspBuf before returning, so the KM TA status word (response word 0) reads 0/success and an ABL that checks the TA response in addition to the transport status can't trip on stale bytes. (BSP callers zero-init their response structs, so it was likely moot for the in-tree path, but the OEM 0x203 caller is unknown, so the defensive write is worth it.)
…drop response Addresses PR #51 review (Codex P1/P2, Copilot): - InstallAll (Codex P1, fail-open regression): revert to keeping SPSS install FATAL under WantProfileSpoof, including EFI_NOT_FOUND. NOT_FOUND is ambiguous — same return whether the SoC lacks an SPU (macan) or an SPU-backed target (canoe/infiniti) failed to publish gEfiSPSSProtocolGuid this boot. Treating all NOT_FOUND as benign would silently boot mode-2 with the SPU KeyMint mirror unhooked = incomplete spoof. Fail closed instead. mode-2 on a known-no-SPU SoC now explicitly deferred to a future capability flag. - SpssHook (Copilot): split honest EFI_NOT_FOUND (benign, return NOT_FOUND) from the EFI_SUCCESS+NULL-interface contract violation (return EFI_DEVICE_ERROR), so a corrupt published handle is never mistaken for "this SoC has no SPU". - QseecomHook (Codex P2): zero RspBuf when swallowing 0x203 so the KM TA status word reads 0 (success). Without it an ABL that checks the TA response in addition to the transport status could read stale bytes and treat the synthetic success as a KM failure. - tests/046: drop the obsolete "InstallAll treats NOT_FOUND benign" assertion; add one asserting the SPSS fatal gate under profile-spoof is intact. Firmware build (-Werror) clean; 045/046/047 lint pass. Docs + memory updated to record the fail-closed decision and the deferred macan-mode-2 capability flag. mode-1 RPMB guard (the safety fix) is unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…turally compatible Reverse-engineering the unwrapped ABL disproves the earlier "sm8845 has no SPU" conclusion: - `gbl unwrap abl_a.img` -> PE that CONTAINS the SPSS protocol GUID a322ff2c-… (off 0x81c3c) plus the full SPU keymint-mirror code (ShareKeyMintInfoWithSPU, SPSSDxe_ShareKeyMintInfo, "Unable to locate SPSS protocol", remoteproc-spss). - Device runs keymint-strongbox (SPU-backed KeyMint HAL). The SPU is a real key/attestation domain on macan. The diag unit's SPSS-absent was its SPU failing PMIC init (SPSSLib_LoadSPSS 0xE), NOT a structural no-SPU SoC. Consequences: - macan is structurally identical to infiniti for mode-2: same SPSS GUID + SPSSDxe_ShareKeyMintInfo slot, same KeyMasterSetRotAndBootState, same KM wire shapes (SET_ROT off12/sz32, SET_BOOT_STATE off16/sz48) that ProfileOverlay / SpssHook already target. No new EFI code needed for mode-2 on macan. - mode-2 profile derivation validated end-to-end on macan stock vbmeta: `gbl mode2 derive` -> valid TOML (GREEN, is_unlocked=0, os=16, spl=2026-01-01) -> `compile` -> valid 120-byte profile. - fail-closed under WantProfileSpoof is correct and there is NO no-SPU flag to build (premise disproven). SPU-up unit publishes SPSS -> hook installs (full spoof, like infiniti); SPU-down unit -> refuse (don't ship a half-spoof while a StrongBox SPU domain exists). Comment + docs + memory only; no behavior change. Firmware build (-Werror) clean; 045/046/047 lint pass. Open question left to device test: is the diag unit's SPU-init failure universal to macan or unit-specific? Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… is dead) The fail-closed gate (commit 56dfe7d) aborted mode-2 to FastbootLib when SPSS install failed under WantProfileSpoof, on the assumption that a published SPSS protocol implies a live SPU keymint enforcement domain that a KM/QSEECOM-only spoof would be inconsistent with (the "half-spoof" Codex flagged). The validated infiniti mode-1 captures disprove that assumption: SPSS publishes and our hook installs (spss=1/1), but the SPU PIL image never loads — pil-SPSS Failed to load metadata SPSSLib:: SPSSLib_LoadSPSS ProcessPilImageExt = Load Error — so the keymint mirror is shared into a protocol whose backing SPU subsystem is absent. macan fails earlier still (PMIC 0xE, protocol never published). On both targets there is no live SPU domain; the KM/QSEECOM spoof is the whole spoof. Failing closed bought no security and only blocked macan mode-2. InstallAll now treats SPSS as best-effort / observation-only: it installs the ShareKeyMintInfo mutator when the protocol is present (keeps the mirror coherent if a healthy SPU ever does enforce) but never aborts the chain-load on its absence, including under profile-spoof. SpssHook still distinguishes benign NOT_FOUND from the EFI_SUCCESS+NULL contract violation for log clarity; both are non-fatal at the policy layer. The mode-1 KM 0x203 / VB device-lock-state RPMB swallows are unchanged and reviewed correct (WRITE_CONFIG/VBReset swallowed, READ_CONFIG/VBDeviceInit cleared, OplusSec 0x0A + KM 0x203 dropped under fakelock). - InstallAll.c: drop WantProfileSpoof FATAL branch; GBL_INFO + continue. - SpssHook.c: update NOT_FOUND comment to best-effort rationale. - tests/046: invert assertion 12 — FATAL gate must be GONE, continue path present. - docs/project/re-findings.md: correct the fail-closed conclusion. Build clean (-Werror) -> dist/gbl-chainload.efi; 045/046/047 pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ch-net Replace the WRITE_CONFIG swallow with a write-side HEAL so the persisted device-state record self-heals toward the device's true (unlocked) state instead of being blocked. Restates the brick-safety rule as one invariant: persistence may only ever move TOWARD unlocked, never toward locked. Per-path enforcement (split by what payload layout we own): - VB READ_CONFIG / VBDeviceInit : read-side spoof -> flags forced to 0 (locked) so ABL behaves locked for attestation (unchanged). - VB WRITE_CONFIG : HEAL -> is_unlocked / is_unlock_critical rewritten to 1 (unlocked) and FORWARDED. The last canonical write to land heals RPMB, so a chain-load-absent next boot finds a recoverable device. NULL / too-small buffer -> overlay returns FALSE and caller fail-safe swallows (never forward a record we can't prove unlocked). Self-enforcing op==WRITE_CONFIG guard. A failed healed forward is now surfaced (GBL_INFO) so a non-landing self-heal is visible in diags. - VB Reset : SWALLOW (no payload to heal). - OplusSec 0x0A : DROP (opaque blob; OS-facing TZ app, no heal pursued). - KM 0x203 : DROP (send buffer is a pointer to an opaque KM device-state struct with no ground truth; can't heal safely today). RE follow-up logged in re-findings to recover the pointee layout so it can be healed instead. Catch-net: QseecomHook now logs any UNRECOGNISED KM-space (0x200-0x2FF) cmd under fakelock (KmIsRecognisedCmd) so a new hidden RPMB-persist path surfaces in --debug diags as an RE candidate instead of bricking silently. Log-only, zero behavior change. OnVbWriteConfig contract changed EFI_STATUS->BOOLEAN (TRUE=forward healed buffer, FALSE=fail-safe swallow). test 046 extended to pin the heal contract, the forward-not-swallow caller path, and the catch-net. Clean -Werror build; tests 045/046/047 pass. NOTE: this changes the validated device (infiniti) from swallow to forward-healed, so non-lock DeviceInfo fields now persist that previously did not. Warrants an infiniti mode-1 staged re-validation before landing. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5b6989fc34
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (EFI_ERROR (Status)) { | ||
| if (gManifest.WantProfileSpoof) { | ||
| Print (L"ProtocolHookLib: FATAL — SPSS install failed (%r), aborting chain-load\n", | ||
| Status); | ||
| return Status; | ||
| } | ||
| Print (L"ProtocolHookLib: SPSS install failed (%r) - continuing (observation-only)\n", | ||
| Status); | ||
| GBL_INFO ("ProtocolHookLib: SPSS install failed (%r) - continuing " | ||
| "(SPU keymint domain is dead on all targets; mirror is best-effort)\n", | ||
| Status); |
There was a problem hiding this comment.
Fresh evidence after the earlier fix: this squashed commit again continues for every InstallSpssHook() error. On a profile-spoof boot for an SPU-backed target whose SPSS protocol fails to publish or whose ShareKeyMintInfo slot is unavailable, this lets the boot proceed after rewriting only QSEECOM/KM, leaving the SPU KeyMint mirror unhooked; that is an incomplete spoof on devices where SPSS normally publishes. Please gate this best-effort path to a proven no-live-SPU capability, or keep SPSS failures fatal under WantProfileSpoof.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Investigated against macan's actual firmware — keeping soft-fail, on two independent grounds.
1. Structural: no failure mode leaves a live mirror unhooked. InstallSpssHook returns non-success only where ABL's own ShareKeyMintInfoWithSPU also can't mirror — LocateProtocol==NOT_FOUND → ABL hits its own NOT_FOUND branch and shares nothing (return EFI_SUCCESS); slot==NULL → ABL would deref the same NULL slot; SUCCESS+NULL → DEVICE_ERROR for ABL too. The only state where ABL successfully mirrors is published + non-NULL + valid-slot — exactly where our LocateProtocol succeeds and we swap the slot. There is no "ABL mirrors the real state while our hook is absent" case.
2. Empirical: the SPU keymint enforcement domain is dead on every target. infiniti publishes SPSS but the PIL never loads (pil-SPSS Failed to load metadata / SPSSLib_LoadSPSS ProcessPilImageExt = Load Error); macan never publishes (SPSSLib_LoadSPSS Creating PMIC clients failed: 0xE → LocateProtocol Not Found). No live second domain to be inconsistent with.
macan is also not on the SMCI/IKMHal keymint path that could bypass us: its own captured logfs.img decodes SET_ROT/SET_BOOT_STATE/SET_VBH(0x211)/0x203/MILESTONE through our QSEECOM hook — the #ifndef AUTO_VIRT_ABL world, whose SMCI counterpart has no ShareKeyMintInfoWithSPU at all. The QSEECOM/KM spoof is the whole live spoof.
Residual: a device with a live SPU keymint domain that publishes SPSS after our install — none in evidence. The spss=1/1 vs 0/1 device reports + the new unrecognised-KM-cmd catch-net surface such a device first; adding strictness there is deferred until one exists. Until then, failing closed only blocks mode-2 on dead-SPU units where nothing reaches the SPU.
| OldUnlocked = B[IsUnlockedOff] ? TRUE : FALSE; | ||
| OldUnlockCritical = B[IsUnlockCriticalOff] ? TRUE : FALSE; | ||
| B[IsUnlockedOff] = 1; | ||
| B[IsUnlockCriticalOff] = 1; |
There was a problem hiding this comment.
When a user is normally unlocked but has not run flashing unlock_critical, the fakelock WRITE_CONFIG heal now persists is_unlock_critical=1 into the canonical DeviceInfo record. That does more than restore the true unlocked boot state: it changes the separate critical-partition unlock policy in RPMB and can leave critical flashing enabled on later boots without the chainload. Please heal only the normal unlock bit, or stash/restore the real critical flag instead of forcing it to unlocked.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Intentional — this is the primary recovery rationale, not an oversight. Forcing is_unlock_critical=1 is precisely so critical flashing stays enabled on later boots without the chainload: if a user wipes EFISP, the patched ABL can no longer chain-load, the device falls back to stock boot over unofficial images, and a persisted critical-locked state leaves them in RED with no fastboot — EDL-only recovery. Persisting critical-unlocked keeps fastboot flashing available so they self-recover without EDL.
The over-statement toward unlocked is the invariant ("persistence may only move toward unlocked") working as designed — the failure it guards (RED + no fastboot + EDL-only) is far worse than a more-permissive critical flag. Stash/restore-the-real-bit would re-introduce exactly the brick we're preventing. (No evidence of an ABL/TZ fuse-vs-RPMB critical cross-check; the BSP treats the two flags independently.) Documented in FakelockOverlay.c + re-findings.md.
…ook); record EFISP recovery rationale Re-review of edk2/ for the alternative #ifdef keymint path, plus the EFISP self-recovery rationale for the WRITE_CONFIG heal forcing is_unlock_critical=1. SPSS soft-fail is correct — direct primary evidence (macan logfs.img, mode-0): - macan compiled the `#ifndef AUTO_VIRT_ABL` (QSEECOM) world, NOT SMCI/IKMHal: its own captured hook log decodes SET_ROT(0x201)/SET_BOOT_STATE(0x208)/ SET_VBH(0x211)/0x203/MILESTONE via our QSEECOM hook. The SMCI build routes KM via IKMHal_sendCmd (zero qsee-km) and has no ShareKeyMintInfoWithSPU at all. - SET_VBH(0x211) firing proves SetVerifiedBootHash ran — the sole caller of ShareKeyMintInfoWithSPU -> SPSSDxe_ShareKeyMintInfo, the one SPU keymint channel, which our SpssHook swaps. No third path exists in the BSP. - SPU is dead on the unit (SPSSLib_LoadSPSS PMIC clients 0xE -> LocateProtocol Not Found). ABL's own ShareKeyMintInfoWithSPU returns EFI_SUCCESS on NOT_FOUND. Conclusion: soft-fail cannot leave a half-spoof — SPSS absent => nothing reaches the SPU; SPSS present => LocateProtocol succeeds => our hook installs => spoof applies. Keeping it fatal would only block mode-2 on dead-SPU macan units. is_unlock_critical heals to 1 deliberately: if a user wipes EFISP (patched ABL can no longer chain-load) and falls back to stock boot over unofficial images, a persisted critical-LOCKED state = RED, no fastboot, EDL-only recovery. Persisting critical-UNLOCKED keeps fastboot recovery so they self-recover without EDL. Comment-only / docs (no binary change); -Werror build clean, test 046 passes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Summary
Adds support for macan / sm8845 (OnePlus 15R ≈ OnePlus Ace 6T) and addresses the two SoC-specific failures reported on it.
Device identity correction: the diag bundle
gbl-chainload-diag-20260604-000513was labelled "Ace 6T / canoe / sm8850", but hard evidence (ABL stringOPLUS SM8845 Attestation,ro.board.platform=sm8845,ro.product.device=macan,ro.product.model=OnePlus 15R) shows it is macan / sm8845 — a different SoC from canoe (sm8850). mode-0 already boots cleanly (detect_oem mapsoneplus→oplus); this PR closes the two sm8845 gaps.1. mode-1 RPMB lock-state brick (the reported failure)
macan issues an OEM-added KM command
WRITE_KM_DEVICE_STATE(cmd0x203,KEYMASTER_UTILS+3) absent from the open QcomModulePkg BSP. The BSP RoT/boot-state path (SET_ROT0x201 +SET_BOOT_STATE0x208) never calls it.Brick-safety invariant (this PR's framing)
The device's true state is unlocked; fakelock makes it appear locked for attestation, but the persistent (RPMB) lock-state must never drift to locked, or a chain-load-absent boot bricks. This PR states the rule as one invariant —
— and enforces it per path by mechanism, because we can only rewrite payloads whose layout we own:
READ_CONFIG/VBDeviceInitDeviceInfo, known0(locked) so ABL behaves locked (unchanged)WRITE_CONFIGDeviceInfo, known1(unlocked) and FORWARDED. The last canonical write self-heals RPMB toward the true state. NULL / too-small → fail-safe swallowReset0x0A0x203{cmd, addr_lo, addr_hi}→ opaque pointee0x203; can't heal safely yet)The earlier revision swallowed VB
WRITE_CONFIG; it now heals + forwards so the canonical record self-heals on any write (enumerated or not — and this additionally repairs a previously-persisted locked record, which the old swallow could not).0x203and0x0Astay dropped underWantFakelockHook, gated to their TA handles inQseecomHook(keymaster handle pinned lazily from the first0x200–0x2FFcmd, since keymaster preloads viaLoadSecureAppsbefore our StartApp hook;0x203zeroesRspBufso the synthetic success carries a clean TA status word). Current-boot attestation (RAM-only0x201/0x208) is unaffected — fakelock still reports locked while never persisting it.Catch-net for un-enumerated persist paths. Beyond the canonical VB record self-healing,
QseecomHooknow logs (KmIsRecognisedCmd) any unrecognized0x200–0x2FFKM command under fakelock, so a new hidden RPMB-persist path (the0x203class) surfaces in--debugdiags as an RE candidate instead of bricking silently. Log-only, zero behavior change.Evidence basis — read this before trusting the mechanism
The primary capture is mode-0, so macan mode-1 behavior is not directly observed. The
0x203guard rests on a controlled comparison with the project's own validated mode-1 capture on infiniti (logs/20260524-012314_manual_mode-1-v2.3.4-installed):0x2010x2080x203Infiniti's validated, non-bricking mode-1 drives a fully locked RoT + boot-state into the KM TA every boot yet survives, because the locked state is ephemeral RAM attestation that is never persisted (infiniti's ABL lacks
0x203entirely). macan adds exactly that one persistence command. Dropping0x203makes macan mode-1 converge onto the KM behavior infiniti is validated safe with.0x203payload is inferred by analogy (infiniti mode-1 + macan mode-0), not observed.0x203→ RPMB is inferred from the command name + the user's brick report + the infiniti control — not confirmed by disassembling its handler. RE follow-up open (inre-findings.md) to recover the{addr_lo, addr_hi}pointee layout so0x203can be healed to unlocked rather than dropped.VB: RWDeviceState: …rpmb!log lines as 0x203 evidence; that was wrong — those are the VB DeviceInfo path. Corrected indocs/project/re-findings.md.--debug --verbosestaged capture.2. SPSS / mode-2 on sm8845 — macan IS SPU-backed; SPSS is now soft-fail
Earlier-draft correction (RE'd against the ABL). A first pass concluded "macan has no SPU, SPSS-absent is structural." Unwrapping the ABL disproves that: the macan PE contains the SPSS GUID
a322ff2c-…(off0x81c3c) and the full mirror code (ShareKeyMintInfoWithSPU,SPSSDxe_ShareKeyMintInfo,remoteproc-spss), and the device runskeymint-strongbox(SPU-backed KeyMint). macan is SPU-equipped. The diag unit'sSPSS → Not Foundwas its SPU failing PMIC init (SPSSLib_LoadSPSS 0xE) on that unit, not a SoC property.So mode-2 on macan needs no new EFI code — it is structurally identical to infiniti. Same SPSS GUID +
SPSSDxe_ShareKeyMintInfoslot ourSpssHookswaps, sameKeyMasterSetRotAndBootState, same KM wire shapes (SET_ROToff12/sz32,SET_BOOT_STATEoff16/sz48) thatProfileOverlay_RewriteKmSend/ProfileOverlay_RewriteSpsstarget. Profile derivation is validated end-to-end on macan's stock vbmeta:gbl mode2 derive→ valid TOML (GREEN,is_unlocked=0, os=16, spl=2026-01-01, rot/pubkey/vbh) →compile→ valid 120-byte profile.SPSS is now SOFT-FAIL / best-effort, NOT fail-closed. The SPU keymint enforcement domain is dead on every target we have evidence for: on infiniti the SPSS protocol publishes and our hook installs (
spss=1/1) but the SPU PIL image never loads (pil-SPSS Failed to load metadata/SPSSLib_LoadSPSS ProcessPilImageExt = Load Error); on the macan unit the protocol is absent (PMIC init0xE). With no live SPU domain, the KM/QSEECOM spoof is the whole spoof — an unhooked mirror is not a half-spoof. SoInstallAllforwards an SPSS install failure toGBL_INFOand continues (never aborts BootFlow to FastbootLib);SpssHookstill returns benignNOT_FOUND/EFI_DEVICE_ERROR(SUCCESS+NULL contract) for observability. This reverses the prior "fail-closed underWantProfileSpoof" stance (the half-spoof concern @chatgpt-codex-connector raised is moot while the SPU enforcement domain is dead). mode-0/mode-1 are unaffected (they never setWantProfileSpoof). If a device with a live SPU keymint domain ever turns up, this is the revisit point — there it would be a genuine half-spoof and a positive capability signal should gate strictness.Open question for device test (no code impact): is the diag unit's SPU-init failure representative of macan or a degraded unit? Either way mode-2 now proceeds — have the owner run mode-2 staged and report
spss=1/1(SPU up) vsspss=0/1(SPU down).Verification
-Werror) clean →dist/gbl-chainload.efi(724992 bytes).VBRwDeviceStatechokepoint the heal sits ahead of); no CRITICAL/HIGH-confidence blockers.tests/046_mode1_protocol_hook_lint.shextended: the VB WRITE_CONFIG heal contract (heal-or-swallowBOOLEAN, forward-not-swallow caller path), the QseecomHook0x203guard +gKeymasterHandletracking, theKmIsRecognisedCmdcatch-net, and the InstallAll SPSS best-effort (not fail-closed) path.045/046/047pass.docs/project/re-findings.md→ "Device: macan / sm8845".On-device validation (owner — safe staged-load path only)
For a mode-1 capture (
--debug --verbose), confirm in the post-boot log:vb-fakelock | WRITE_CONFIG | … healed->unlocked … forwarding— the heal firingvb-rwstate | op=WRITE | bufLen=…— bufLen ≈ 3344 (matches ourDeviceInfolayout; a different value means macan's struct layout differs and the heal offsets need re-checking)qsee-km | cmd=0x00000203(WRITE_KM_DEVICE_STATE) | DROPPEDUNRECOGNISED KM cmd under fakelockline — a candidate un-guarded persist path to RE before trusting mode-1The VB
WRITE_CONFIGswallow → forward-heal also changes infiniti (the only validated device): non-lockDeviceInfofields (rollback indices, FRS material viaKeyMasterGetFRSAndUDS, audio framework…) now persist where the swallow previously blocked them. The lock invariant is clean and this is closer to stock behavior, but infiniti was validated under swallow — an infiniti mode-1 staged re-validation is the honest precondition before relying on this on new hardware.is_unlock_criticalis healed to1(recovery direction — un-bricks a previously-locked record); a safer-but-non-healing alternative is to restore the read-observed true value.This PR prevents new bricks and (via the VB heal) can repair a previously fake-locked DeviceInfo record; it does not repair a brick persisted via
0x203/0x0Aon a prior install (those are dropped, not healed) — that recovery is a separate investigation.Notes
VERSION/CHANGELOGbump here (version bumps land as their own focused PR per CLAUDE.md).-DPRODUCT_NAME="canoe"(cosmetic getvar label) — left as-is.🤖 Generated with Claude Code