Add support for HWKM v1 based In-line Crypto Engine - #42
Open
Harshal Dev (harshaldev27) wants to merge 13 commits into
Open
Harshal Dev (harshaldev27) wants to merge 13 commits into
Harshal Dev (harshaldev27) wants to merge 13 commits into
Conversation
Harshal Dev (harshaldev27)
force-pushed
the
ice-hwkm-v1
branch
from
August 14, 2026 14:30
845359e to
8b15785
Compare
Harshal Dev (harshaldev27)
force-pushed
the
ice-hwkm-v1
branch
2 times, most recently
from
August 30, 2026 15:50
3e6ccd6 to
204d614
Compare
Sumit Garg (b49020)
force-pushed
the
qcom-next
branch
2 times, most recently
from
September 7, 2026 07:43
1a117cb to
dab3efd
Compare
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>
Harshal Dev (harshaldev27)
force-pushed
the
ice-hwkm-v1
branch
2 times, most recently
from
September 16, 2026 10:59
ce0f312 to
6ed3b77
Compare
Harshal Dev (harshaldev27)
marked this pull request as ready for review
September 16, 2026 11:41
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>
Harshal Dev (harshaldev27)
force-pushed
the
ice-hwkm-v1
branch
from
September 17, 2026 15:54
6ed3b77 to
a8f077d
Compare
Contributor
Author
Done, only 3 commits from his PR related to HWKM re-factoring and GPCE slave addition are now kept. |
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
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.
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:
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.
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