6.2. Crypto engine (QCE) and hardware RNG

The SoC has a general-purpose Crypto Engine (CE) — a bulk cipher/hash/AEAD accelerator with its own BAM DMA — plus a hardware RNG. This is distinct from the UFS Inline Crypto Engine (ICE) that does storage file-based encryption (Boot image: kernel, DTB, ramdisk, config, Storage controllers — UFS, ICE, and SDCC): ICE encrypts data on the way to/from UFS, the CE is the offload block for everything else (dm-crypt, IPsec/MACsec, KeyMaster/QSEE key operations, userspace crypto). All facts are from artifacts/boot_a/board.dts and kernel_config.txt.

6.2.1. The Crypto Engine

One CE hardware instance, shared between the HLOS and the secure world:

  • Registers: CE core 0x1de0000 (size 0x20000) + CE-BAM DMA 0x1dc4000 (size 0x24000); IRQ 0x110. (Same 0x1dxxxxx band as the UFS host, Storage controllers — UFS, ICE, and SDCC.)

  • qcom,ce-hw-instance = 0, qcom,ce-device = 0, qcom,bam-ee = 0 — a single engine on BAM execution-environment 0.

  • ``qcom,ce-hw-shared`` — the CE is shared with TZ/QSEE: the same block services KeyMaster/QSEE key operations (Secure world and coprocessors (TZ, HYP, trustlets)) and HLOS requests, arbitrated through separate BAM pipe pairs.

Two HLOS personalities sit on that one engine, each on its own BAM pipe pair:

Node

BAM pipes

Consumer

qcom,qcrypto

pair 2

the Linux Crypto-API backend — transforms for dm-crypt, IPsec, etc.

qcom,qcedev

pair 3

the ``/dev/qce`` char device — userspace / QSEE-side cipher & hash offload

Both are SMMU-isolated: the qcom,qcedev,context-bank children take apps-SMMU streams (iommus = <0x17 …>, SIDs 0x432/0x438/0x43f and 0x433/0x43c/0x43e) so CE DMA is translated like the other NoC masters (Base kernel device tree (the SoC boot contract)).

6.2.2. Kernel drivers

The -perf config selects the Qualcomm downstream CE stack, not the upstream generic one:

  • CONFIG_CRYPTO_DEV_QCOM_MSM_QCE = y — the CE core driver.

  • CONFIG_CRYPTO_DEV_QCRYPTO = y (Crypto-API) and CONFIG_CRYPTO_DEV_QCEDEV = y (/dev/qce).

  • CONFIG_CRYPTO_DEV_QCE not set — the mainline QCE driver is off (the downstream MSM_QCE is used instead).

  • CONFIG_CRYPTO_DEV_QCOM_ICE not set — storage crypto is done through SCSI_UFS_CRYPTO (inline ICE), not the old standalone ICE driver.

6.2.3. Hardware RNG

  • qcom,msm-rng at ``0x793000`` (size 0x1000), qcom,msm-rng-iface-clk, qcom,no-qrng-config — the on-die PRNG/TRNG.

  • Exposed to the kernel by CONFIG_HW_RANDOM = y + CONFIG_HW_RANDOM_MSM_LEGACY = y (feeds /dev/hwrng and the entropy pool). The newer CONFIG_CRYPTO_DEV_QCOM_RNG is not set — the legacy hwrng path is the one in use.

6.2.4. Where it fits

The CE is the third distinct crypto surface on this device:

Surface

Role

CE (this page)

bulk cipher/hash/AEAD for dm-crypt, IPsec, KeyMaster/QSEE, /dev/qce

UFS ICE

inline file-based storage encryption (FBE), Boot image: kernel, DTB, ramdisk, config

KeyMaster / QSEE (TZ)

key storage and attestation at EL3/secure world (Secure world and coprocessors (TZ, HYP, trustlets)); its bulk crypto lands back on this same shared CE

msm-rng

entropy source (/dev/hwrng)

6.2.5. Provenance

Source:

artifacts/boot_a/board.dts (qcom,qcrypto / qcom,qcedev / context-banks / qcom,msm-rng nodes — addresses, IRQ, BAM pipe pairs, SMMU SIDs) and artifacts/boot_a/kernel_config.txt (CE/RNG driver selection).

Method:

DTB node reading and kernel-config cross-check. No code executed.

Cross-refs:

Base kernel device tree (the SoC boot contract) (apps-SMMU), Storage controllers — UFS, ICE, and SDCC (register band, UFS ICE), Boot image: kernel, DTB, ramdisk, config (FBE / dm-crypt / dm-default-key), Secure world and coprocessors (TZ, HYP, trustlets) (KeyMaster/QSEE, ce-hw-shared with TZ).