ta/pta: qcom: pas: authenticate PIL firmware signatures and device bindings

[zelvam95]

Stacked on PR #7885 (yet to be merged) - which added segment-hash
verification. Segment hashing proves an image matches its own digest table,
but not that the image was signed by a trusted party or is permitted on this
device. On a fused secure-boot Lemans device this PR establishes the image's
provenance at INIT_IMAGE, before the REE loads any segment:
OEM certificate chain, signature, and SW/HW device bindings, all anchored to
hardware fuses. Enabled under the same CFG_QCOM_PAS_AUTH knob as
PR #7885.

Devices whose secure-boot fuse is unblown skip signature authentication and
rely on PR #7885's segment-hash verification alone; segment re-hashing at
AUTH_AND_RESET runs on every device regardless.

Design

Authentication forks on a single fuse read of the secure-boot state and
root-of-trust anchor, and that read fails closed: a fuse-PTA error is
treated as secure-boot enabled, so a transient glitch can never downgrade a
secure-booted board to hash-only verification.

The crypto runs in the qcom_pas user-TA (mbedTLS-backed cert-chain and
signature verification); fuses are reached through a dedicated fuse PTA so the
TA needs no direct driver dependency. UIE-encrypted and QTI-countersigned
images are refused outright — neither decryption nor countersignature
verification is implemented here.

sequenceDiagram
    participant REE as REE (Linux)
    participant TA as qcom_pas TA
    participant FPTA as fuse PTA
    participant PTA as PAS PTA

    Note over REE,PTA: INIT_IMAGE - signature authentication (secure-boot devices)
    REE->>TA: INIT_IMAGE(pas_id, metadata_blob)
    TA->>PTA: PTA_QCOM_PAS_INIT_IMAGE
    PTA-->>TA: TEE_SUCCESS
    TA->>TA: pas_auth_save_metadata()<br/>TEE-private copy keyed by pas_id
    TA->>FPTA: read secure-boot state + root-of-trust anchor
    FPTA-->>TA: secboot_on, anchor<br/>(read error is treated as secboot_on)
    alt secure boot enabled
        TA->>TA: pas_mbn_parse() extracts hash_table
        TA->>FPTA: read device id fuses
        FPTA-->>TA: fuse values
        TA->>TA: verify cert chain vs fused anchor
        TA->>TA: verify signature over OEM-signed region
        TA->>TA: enforce SW/HW bindings
    else secure boot disabled
        TA->>TA: pas_mbn_parse() extracts hash_table<br/>(no signature auth)
    end
    TA-->>REE: TEE_SUCCESS (or TEE_ERROR_SECURITY on any failure)

    Note over REE,PTA: MEM_SETUP + REE segment load (unchanged from PR 19)

    Note over REE,PTA: AUTH_AND_RESET - segment hash verification + release
    REE->>TA: AUTH_AND_RESET(pas_id, fw_base, fw_size)
    TA->>PTA: PTA_QCOM_PAS_VERIFY_IMAGE with metadata and hash_table
    PTA->>PTA: re-hash each PT_LOAD segment vs hash_table entry
    PTA-->>TA: TEE_SUCCESS
    TA->>PTA: PTA_QCOM_PAS_AUTH_AND_RESET
    PTA-->>TA: TEE_SUCCESS peripheral released from reset
    TA-->>REE: TEE_SUCCESS

Loading

Any failure — cert-chain break, signature mismatch, or an SW/HW-binding
mismatch — fails INIT_IMAGE with TEE_ERROR_SECURITY;
the image is never loaded and the peripheral is never released from reset.

Testing

• Built PLATFORM=qcom-lemans CFG_QCOM_PAS_AUTH=y CFG_WERROR=y; checkpatch
  clean across the series.
• On a Lemans board, both fuse configurations:
  • secure-boot on: positive path authenticates and boots; signature mismatch,
    cert-chain break, and SW/HW-binding mismatch are each rejected and the
    peripheral stays in reset;
  • secure-boot off: signature path skipped, segment-hash verification still
    enforced.

[github-actions]

FYI @kishorebatta-ossqcom @ldts @b49020

[jenswikl]

How about making this a draft, since it still depends on other PRs to be merged?
That should help with keeping focus on the PRs that are next in line.

[zelvam95]

How about making this a draft, since it still depends on other PRs to be merged? That should help with keeping focus on the PRs that are next in line.

Sorry, missed to mark as draft. Have moved this PR to draft.

[zelvam95]

@ldts / @harshaldev27 / @kishorebatta-ossqcom,

Have addressed the earlier comments. Let me know if you have any other feedback.

[kishorebatta-ossqcom]

Reviewed core/drivers/qcom/qfprom/* files.

Reviewed-by: Kishore Batta kishore.batta@oss.qualcomm.com