Repository navigation
Apply the StrongBox instance's own attestation-version ceiling - #318
Draft
JingMatrix wants to merge 1 commit into
Draft
JingMatrix wants to merge 1 commit into
JingMatrix wants to merge 1 commit into
Conversation
JingMatrix
force-pushed
the
fix/strongbox-attestation-version
branch
from
October 19, 2026 17:47
adf9737 to
df106e8
Compare
StrongBox is a separate HAL service declaring its own version -- a Pixel 11 declares KeyMint 6 for 'default' and 4 for 'strongbox' -- but with no working hardware the push path reused the TEE's fabricated version outright, so StrongBox keys attested 500 against a declared 400. That is the one thing check_attestation_version forbids; reporting below a declared version it allows explicitly. presentedStrongBoxVersion now caps the TEE figure by the strongbox instance's own ceiling. The clamp no longer borrows a CEILING from 'default', only an EXACT Keymaster mapping that both levels genuinely share, and it records its result as an override rather than overwriting the capture -- harvested.json claimed the device captured 200 where it captured 300. The log names the instance the figure came from.
JingMatrix
force-pushed
the
fix/strongbox-attestation-version
branch
from
October 19, 2026 17:52
df106e8 to
3a70522
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
WIP — builds, but the open questions below are unsettled and no log exercises the new path yet.
StrongBox is a separate HAL service with its own declared version, and may sit generations below the TEE's: the Pixel 11 in #310 declares KeyMint 6 for
defaultand 4 forstrongbox. With no working hardware the push path reused the TEE's fabricated version, so that device attested StrongBox keys at 500 against a declared 400: the one thingcheck_attestation_versionforbids, while reporting below it allows explicitly.presentedStrongBoxVersionnow caps the TEE figure by thestrongboxinstance's own ceiling.Two smaller defects go with it. The clamp borrowed
default's constraint when nostrongboxinstance was declared, which can only over-estimate; it now borrows only an EXACT Keymaster mapping both levels share. And it overwrote the capture instead of recording an override, so harvested.json claimed a capture of 200 where the harvest captured 300.Across the logs I have: #310 fixed, #279, #313 and lvyin555's OnePlus unchanged.
Open:
strongBoxAttestationVersionjoinedSYNTHESIZED_FIELDS, adding an editable WebUI row; and the fallback still hardcodes 300, legal but belowcert.rs's MODULE_HASH gate of 400.