Skip to content

Add support for HWKM v1 based In-line Crypto Engine - #42

Open
Harshal Dev (harshaldev27) wants to merge 13 commits into
qualcomm-linux:qcom-nextfrom
harshaldev27:ice-hwkm-v1
Open

Harshal Dev (harshaldev27) wants to merge 13 commits into
qualcomm-linux:qcom-nextfrom
harshaldev27:ice-hwkm-v1

Conversation

@harshaldev27

@harshaldev27 Harshal Dev (harshaldev27) commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

All Qualcomm SoCs support an In-line Crypto Engine (ICE) hardware block within either the UFS or eMMC storage controller. When storage data moves through the ICE it encrypts or decrypts it using a key programmed within its slot. This patch series introduces a Pseudo-TA for the ICE that allows the Linux side ICE driver [1] to generate a key for ICE programming via version 1 of the Hardware Key Manager (HWKM) and program it within one of its slots to enable storage encryption and decryption.

The storage key is either generated by HWKM (recommended) or imported within one of its slots via Linux. Once the storage key is available within a HWKM slot, the HWKM can directly push it into an ICE key slot after wrapping it via a Transport key (TPKEY). This ensures that the key is only ever visible to trusted software (OP-TEE) or hardware (HWKM/ICE).

Linux always obtains the storage key in a wrapped blob format, ensuring that it never leaves the trust boundary. For the purpose of wrapping the storage key, a hardware derived L4 key is used, which is derived from a per-chip unique derivation key (UKDK L4 key) available within the HWKM. When the L4 key derivation process mixes a per-boot random ephemeral seed, the returned wrapped storage key is called an ephemeral key and cannot be used across device reboots. This provides an additional layer of security by tying the wrapped blob to the current device boot session.

Outline of this patch series:

  • Patch 1 adds support for generating a SWAP and TPKEY within HWKM during its initialization. The SWAP key is used for exporting a key from HWKM within software which must never leave the hardware in clear form. The TPKEY is used for wrapping keys when transporting them between HWKM and its slaves.
  • Patch 2 adds support for ICE slave to the HWKM driver to allow provisioning of ICE keys directly via HWKM.
  • Patches 4 to 9 add the ICE Psuedo-TA which is called by Linux to generate, prepare, program or clear the ICE key. It also allows using the ICE key to generate a software secret via standard CMAC operation.

Dependencies

This PR depends on PR #52 and will be re-based once merged. This dependency is with respect to boiler plate code added in this PR for extending the HWKM slave support via GPCE. This PR is already reviewed in #28.

Validation:

Currently, since the Linux side patch for this series is under work, only Unit testing has been done which should be sufficient for qcom-next. The test driver [2] was used to generate a hardware wrapped key, wrap it via an ephemeral key and then program it into the ICE key slot 10. Afterwards, the slot was also cleared using the same test driver. The Linux fscrypt framework [3] calls the ICE commands in the same sequence when using hardware-wrapped keys.

CMD 1: Generate a HW wrapped key.
CMD 2: Prepare the HW wrapped key via wrapping via epehemeral key.
CMD 3: Import a raw key into the HWKM slot.
CMD 4: Program the key into ICE slot 10.
CMD 5: Clear the key from ICE slot 10.
CMD 6: Use the HW wrapped key to generate a software secret.

# echo 1 > /proc/qcom_ice_pta_test
[   91.955101] qcom_ice_pta_test: cmd=2 rc=0 pta_ret=0x0 origin=0x4
[   91.961299] qcom_ice_pta_test: generated L4 wrapped key size=68
[   91.967399] qcom_ice_pta_test: blob 00000000: b6 74 7f a6 59 d0 ce 43 cf c4 f8 d4 76 44 f0 98
[   91.976164] qcom_ice_pta_test: blob 00000010: 25 63 ef f4 eb 5a b2 7e c6 db da c6 87 9d af 11
[   91.984936] qcom_ice_pta_test: blob 00000020: 55 f8 f6 d2 25 4e 6b ec db 3a 06 85 da 4b 87 54
[   91.993694] qcom_ice_pta_test: blob 00000030: 14 18 01 52 03 00 00 00 00 00 00 00 00 00 00 00
[   92.002462] qcom_ice_pta_test: blob 00000040: 00 00 00 00
[   92.008019] qcom_ice_pta_test: dumped generate (68 bytes)
[   92.013576] qcom_ice_pta_test: command 1 done
# echo 2 > /proc/qcom_ice_pta_test
[   98.163330] qcom_ice_pta_test: cmd=4 rc=0 pta_ret=0x0 origin=0x4
[   98.169523] qcom_ice_pta_test: prepared/exported ephemeral wrapped key size=68
[   98.176962] qcom_ice_pta_test: blob 00000000: 1b 4e 58 7a d7 a3 99 e6 5f fc 25 b4 4b d9 d3 89
[   98.185731] qcom_ice_pta_test: blob 00000010: 15 36 bc 03 c0 9c bd c6 fa 1e 56 90 26 a6 0d c9
[   98.194503] qcom_ice_pta_test: blob 00000020: 4e ac 33 83 89 06 5a c7 41 33 30 31 95 53 46 6c
[   98.203261] qcom_ice_pta_test: blob 00000030: 14 18 01 52 03 00 00 00 00 00 00 00 00 00 00 00
[   98.212025] qcom_ice_pta_test: blob 00000040: 00 00 00 00
[   98.217582] qcom_ice_pta_test: dumped prepare-ephemeral (68 bytes)
[   98.223942] qcom_ice_pta_test: command 2 done
# echo 4 > /proc/qcom_ice_pta_test
[  102.401444] qcom_ice_pta_test: cmd=1 rc=0 pta_ret=0x0 origin=0x4
[  102.407654] qcom_ice_pta_test: command 4 done
# echo 5 > /proc/qcom_ice_pta_test
[  107.410041] qcom_ice_pta_test: cmd=0 rc=0 pta_ret=0x0 origin=0x4
[  107.416275] qcom_ice_pta_test: command 5 done
# echo 6 > /proc/qcom_ice_pta_test
[ 1268.239465] qcom_ice_pta_test: cmd=5 rc=0 pta_ret=0x0 origin=0x4
[ 1268.245678] qcom_ice_pta_test: derived raw secret size=32
[ 1268.251250] qcom_ice_pta_test: blob 00000000: 7a 40 7d af 63 2b 12 51 40 a5 8d 27 3a 53 51 aa
[ 1268.260020] qcom_ice_pta_test: blob 00000010: 3a e7 ad 55 93 ad ce d3 59 9f 8b 92 a8 28 aa d3
[ 1268.268790] qcom_ice_pta_test: dumped raw-secret (32 bytes)
[ 1268.274525] qcom_ice_pta_test: command 6 done

References:
[1] https://elixir.bootlin.com/linux/v7.2-rc7/source/drivers/soc/qcom/ice.c
[2] harshaldev27/kernel-topics@e7b9b86
[3] https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html

Comment thread core/drivers/crypto/qcom/hwkm/transaction.c Outdated
@b49020
Sumit Garg (b49020) force-pushed the qcom-next branch 2 times, most recently from 1a117cb to dab3efd Compare September 7, 2026 07:43
Move the HWKM implementation, HUK support, transaction layer, and
private headers under qcom/hwkm. Keep qcom as the umbrella for
independent Qualcomm crypto IP blocks.

No functional change.

Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
…nces

Change all register offsets in hwkm_regs.h to group-relative and add
HWKM_MASTER_*_REGS_OFFSET and HWKM_CRYPTO0_*_REGS_OFFSET constants to
locate each register group within its instance's MMIO window. Callers
add the appropriate offset at the call site, making the same register
definitions reusable across the master and any slave.

Also extract run_fifo_transaction() from master_run_transaction() so
the FIFO protocol can be reused by any slave.

Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
Enable the CRYPTO0 general-purpose crypto engine (GPCE) key-manager
slave so that keys can be provisioned into CRYPTO0 key slots using the
existing HWKM transaction protocol.

Map the CRYPTO0 MMIO window, configure the key-manager slave at boot,
and extend the transaction layer to dispatch to the GPCE slave alongside
the existing HWKM master.

Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
@harshaldev27
Harshal Dev (harshaldev27) force-pushed the ice-hwkm-v1 branch 2 times, most recently from ce0f312 to 6ed3b77 Compare September 16, 2026 10:59
@harshaldev27 Harshal Dev (harshaldev27) changed the title Add support for Hardware key manager v1 based In-line Crypto Engine Add support for HWKM v1 based In-line Crypto Engine Sep 16, 2026
@harshaldev27
Harshal Dev (harshaldev27) marked this pull request as ready for review September 16, 2026 11:41
@b49020

Copy link
Copy Markdown
Member

Harshal Dev (@harshaldev27) can you rather only pick HWKM patches from Amirreza Zarrabi (@qc-azarrabi) PR which the ICE feature depends upon? This can untangle GPCE and ICE PRs.

Add support for generating the SWAP and TPKEY during driver init.
The TPKEY is used to wrap keys before transporting them to the HWMK slaves,
such as the General Purpose Crypto Engine (GPCE) and the Inline Crypto
Engine (ICE). The SWAP key is used for wrapping and exporting keys from the
hardware key manager to software.

Assisted-by: Codex:gpt-5.3-codex
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Add support for the Inline Crypto Engine (ICE) slave to the hardware key
manager (HWKM). This allows HWKM to issue commands to ICE and provision
keys via its existing transaction protocol.

Since the clock and power for ICE are controlled by Linux, it must be
(re)configured before dispatching any transactions to it.

Assisted-by: Codex:gpt-5.3-codex
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Export the interface to the Qualcomm hardware key manager (HWKM) drivers
by moving the hwkm.h and hwkm_errno.h files to include/drivers/ path.

Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Add a pseudo-TA for the Qualcomm Inline Crypto Engine (ICE) that lets the
kernel inline-crypt path generate a wrapped L4 key derived from the unique
key derivation key (UKDK) available with the Hardware Key manager for
inline storage encryption.

Only the REE kernel may open a session on this PTA. The PTA is gated by
CFG_ICE_FS_ENC_PTA and is not built unless a platform enables it.

Assisted-by: Codex:gpt-5.3-codex
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Add support for importing and wrapping a key with a UKDK-derived L4 key.
The wrapped key is returned to the REE which can use it as a storage
key.

Assisted-by: Codex:gpt-5.3-codex
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Add support for exporting a key after un-wrapping it with a UKDK-derived
L4 key and re-wrapping with an ephemeral key (also a HW derived UKDK L4
key). This ties the storage key with a per boot generated random seed.

Assisted-by: Codex:gpt-5.3-codex
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Add support for programming an ephemerally wrapped key into a specified
inline crypto engine (ICE) key slot.

The key is first unwrapped via the ephemeral key, and then wrapped by
a TP (transport) key before being imported into the ICE hardware block
via the hardware key manager.

Assisted-by: Codex:gpt-5.3-codex
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Add support for invalidating a previously programmed key from the inline
crypto engine's (ICE) key slot via the hardware key manager.

Assisted-by: Codex:gpt-5.3-codex
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Add support for deriving a software secret from the ephemerally
wrapped key. The key is unwrapped via HWKM and a CMAC operation
is performed on it to generate and return a raw secret to the
REE.

Assisted-by: Codex:gpt-5.3-codex
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Enable the in-line crypto engine Psuedo TA for Lemans to allow encryption
of storage contents with key programming done via the Hardware key manager.

Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
@harshaldev27

Copy link
Copy Markdown
Contributor Author

Harshal Dev (Harshal Dev (@harshaldev27)) can you rather only pick HWKM patches from Amirreza Zarrabi (Amirreza Zarrabi (@qc-azarrabi)) PR which the ICE feature depends upon? This can untangle GPCE and ICE PRs.

Done, only 3 commits from his PR related to HWKM re-factoring and GPCE slave addition are now kept.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants