ta: qcom_pas: anti-rollback enforcement and multi-root certificate selection - #7971
Draft
zelvam95 wants to merge 13 commits into
Draft
ta: qcom_pas: anti-rollback enforcement and multi-root certificate selection#7971zelvam95 wants to merge 13 commits into
zelvam95 wants to merge 13 commits into
Conversation
Signature authentication will trust the carveout more heavily than hash-only verification does, and its TA-side policy will need the same PAS IDs core code already uses, so put both in place before the rest of the series builds on them. The carveout base and size come from the REE, so the range must be proven non-secure memory before it is mapped for hashing, and the REE writes it outside this mapping's coherency domain, so hashing could otherwise see a stale cached copy. Also reject an ELF with inconsistent header geometry, so segment collection cannot run on a malformed image. PAS authentication verifies the firmware contents. TOCTOU protection for the carveout is expected to come from the kernel/HYP MMU/SMMU configuration, which controls isolation between non-secure masters. Move the PAS_ID_* constants out of the core-only pas_data.h and into the shared pta_qcom_pas.h interface header, so the TA-side policy code added later in this series references the same values instead of a second, duplicated set. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Assisted-by: Claude:sonnet-5 Reviewed-by: Sachin Grover <sgrover@qti.qualcomm.com>
The secure-boot fuse accessors need per-target register offsets, masks and layout to operate. Keep the Lemans values as driver platform data so a future target only needs its own register layout, not a copy of the reader code. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Assisted-by: Claude:sonnet-5 Reviewed-by: Sachin Grover <sgrover@qti.qualcomm.com> Reviewed-by: Kishore Batta <kishore.batta@oss.qualcomm.com>
zelvam95
marked this pull request as draft
August 30, 2026 13:22
Signature authentication has to bind an image to the device it runs on, which requires the OEM root-of-trust anchor and enable state, the device identity, and the EKU enforcement fuse. They are gated on CFG_QCOM_FUSE_PTA so a target without the fuse PTA carries none of this code. No caller reads them yet. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Assisted-by: Claude:sonnet-5 Reviewed-by: Sachin Grover <sgrover@qti.qualcomm.com> Reviewed-by: Kishore Batta <kishore.batta@oss.qualcomm.com>
The secure-boot fuse readers live in the OP-TEE core, but the PAS TA that needs them runs in user space. Expose them through a pseudo-TA restricted to a REE_KERNEL-only login domain, so the TA can obtain fuse-backed values without a driver dependency of its own. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Assisted-by: Claude:sonnet-5 Reviewed-by: Sachin Grover <sgrover@qti.qualcomm.com>
…rser Signature authentication binds an image to its device using fields in the OEM metadata block. Decode the block into typed values, including anti-rollback and secondary SW ID fields for follow-on checks, so the authentication backend never re-parses the raw block. Metadata version and root_cert_sel are readable on their own, because each selects the hash size the full parse needs as input. The OEM-signed region masks out the QC-controlled fields, so the signature covers exactly what the OEM signed. Replace the hash-segment parser's raw byte-offset macros and untyped u32 reads with a typed MBN header struct, since the decoder above and the parser's other callers all dereference the same fields and byte-offset arithmetic is easy to get wrong on review. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Assisted-by: Claude:sonnet-5 Reviewed-by: Sachin Grover <sgrover@qti.qualcomm.com>
The signature-authentication path makes several fuse reads per image, so hold one fuse-PTA session per TA session rather than opening one per read, matching how the TA already holds its PAS PTA session. The helper applies no policy and fails closed: a read failure propagates instead of substituting a default, so an untrustworthy fuse value aborts authentication rather than silently weakening it. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Assisted-by: Claude:sonnet-5 Reviewed-by: Sachin Grover <sgrover@qti.qualcomm.com>
Segment-hash verification proves an image matches its own digest table; it cannot prove who signed it or that it is permitted on this device, so establish provenance before the peripheral leaves reset. The fuse read selecting this path fails closed: an error means secure boot enabled, so a transient failure cannot downgrade a fused board to hash-only verification. UIE-encrypted and QC-countersigned images are refused, as neither is implemented here, and the chain is limited to one ECDSA P-384 root. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Assisted-by: Claude:sonnet-5 Reviewed-by: Sachin Grover <sgrover@qti.qualcomm.com>
…cation Signature authentication reads fuses at runtime, so CFG_QCOM_PAS_AUTH alone is not enough: the fuse PTA and the qfprom driver behind it must come up with it too. Fold the existing fuse-provisioning enable into the same block so it and the new fuse-PTA consumer share one QFPROM enable and cannot drift apart. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Assisted-by: Claude:sonnet-5 Reviewed-by: Sachin Grover <sgrover@qti.qualcomm.com>
A later PAS-TA change must reject firmware older than the device's anti-rollback floor and advance that floor once a newer image is authenticated; both need the PIL ARB fuse. The accessors fail closed, reporting version 0 for enforcement off unless secure boot and the PIL ARB enable fuse are both blown. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Assisted-by: Claude:sonnet-5
A later PAS-TA change must enforce which provisioned root a signed image may chain to, which needs the root count and the per-index activation and revocation state. Selection only exists when the anchor is fuse-resident and more than one root is provisioned; otherwise the accessor reports the single-root default, so such devices need no multi-root handling. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Assisted-by: Claude:sonnet-5
The new secboot accessors live in the OP-TEE core, but the qcom_pas TA that enforces anti-rollback and root selection runs in user space, so each must be reachable through the fuse PTA. The anti-rollback blow-write is this PTA's only mutating command; the existing open-session restriction to qcom_pas already covers it. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Assisted-by: Claude:sonnet-5
Wrap the new fuse-PTA commands so the authentication path reads these fuses through one helper instead of invoking the PTA inline. The multi-root reader keeps the single-root default when the PTA reports selection disabled, so single-root callers see no change. Access failures propagate so callers fail closed. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Assisted-by: Claude:sonnet-5
Enforce the two policies the preceding fuse plumbing made available. Anti-rollback rejects firmware below the device floor, and the floor advances only after the image's segments are verified, so a rejected image cannot raise it. Multi-root selection binds the chain to the root the image nominates, checked against the device activation and revocation lists. Both fuse reads fail closed. Single-root devices and MBN v5 images, which carry no OEM metadata, are unaffected. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Assisted-by: Claude:sonnet-5
zelvam95
force-pushed
the
feature/optee-pas-arb-mrc
branch
from
August 30, 2026 13:28
6436b23 to
5d3eb8c
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
1 participant
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.
Dependencies / stacking
This PR is stacked on: PR #7937. This needs to be reviewed and merged after the base PR is merged.
This PR builds on the PAS firmware-authentication work to add two hardware-backed
security enforcements to the image authentication path:
Anti-rollback (ARB): rejects firmware whose rollback version is older
than the value fused on the device, and advances the on-device fuse version
when a newer, successfully-authenticated image is loaded. This prevents an
attacker from downgrading a peripheral to a known-vulnerable signed image.
Multi-root certificate (MRC) selection: allows the signed image's
certificate chain to be validated against one of several provisioned root
certificates, honoring the fuse-programmed activation/revocation state so a
revoked root can no longer authorize firmware.
Both features extend the existing chain: QFPROM driver accessors expose the
relevant fuses, the fuse PTA surfaces them to the TA, and the PAS TA consumes
them during authentication. When the relevant fuses are unprovisioned the
behavior is unchanged from the base authentication flow (single root, no
rollback enforcement), so this is additive and backward compatible.