======================================== 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 (:doc:`/boot/boot-image`, :doc:`/soc/storage`): 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``. 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, :doc:`/soc/storage`.) - ``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 (:doc:`/trustzone/secure-world`) and HLOS requests, arbitrated through separate BAM pipe pairs. Two HLOS personalities sit on that one engine, each on its own BAM pipe pair: .. list-table:: :header-rows: 1 :widths: 22 14 64 * - 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 (:doc:`/boot/base-dtb`). 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. 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. Where it fits ============= The CE is the third distinct crypto surface on this device: .. list-table:: :header-rows: 1 :widths: 26 74 * - 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), :doc:`/boot/boot-image` * - **KeyMaster / QSEE (TZ)** - key storage and attestation at EL3/secure world (:doc:`/trustzone/secure-world`); its bulk crypto lands back on this same shared CE * - **msm-rng** - entropy source (``/dev/hwrng``) 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: :doc:`/boot/base-dtb` (apps-SMMU), :doc:`/soc/storage` (register band, UFS ICE), :doc:`/boot/boot-image` (FBE / dm-crypt / dm-default-key), :doc:`/trustzone/secure-world` (KeyMaster/QSEE, ``ce-hw-shared`` with TZ).