drivers/crypto: add Qualcomm Hardware Key Manager (HWKM) driver#10
Open
qc-azarrabi wants to merge 4 commits into
Open
drivers/crypto: add Qualcomm Hardware Key Manager (HWKM) driver#10qc-azarrabi wants to merge 4 commits into
qc-azarrabi wants to merge 4 commits into
Conversation
Member
|
@T0nyJH fyi.. |
ldts
reviewed
Apr 27, 2026
| * | ||
| * Return: TEE_SUCCESS on success, or a TEE_ERROR_* code on failure. | ||
| */ | ||
| TEE_Result tee_otp_get_hw_unique_key(struct tee_hw_unique_key *hwkey) |
Contributor
There was a problem hiding this comment.
instead of repeating the same pattern for each phase, is it possible that we can extract the pattern into a static function?
Member
|
Please rebase to the tip of qcom-next as it has been rebased to tip of upstream master to include the merged PAS patch-set as well as latest fuse driver patch-set from Selvam. |
675fed5 to
9355517
Compare
Implement a diagnostic ring buffer driver that preserves crash logs in IMEM across reboots for post-mortem analysis. The driver provides a write-only circular buffer that captures console output during normal operation and crash scenarios. Key features: - Write-only circular buffer in IMEM for crash log preservation - DLOAD mode detection to disable logging during download mode - Automatic buffer wraparound with overflow tracking Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
Integrate the diagnostic ring buffer driver into the platform: - Add IMEM memory region definitions (platform_config.h) * Kodiak: 0x14680000, size 0x19000 * Lemans: 0x14680000, size 0x32000 - Enable CFG_QCOM_DIAG_LOG in debug builds (conf.mk) * Automatically enabled when CFG_TEE_CORE_DEBUG=y - Hook into trace infrastructure * Initialize DIAG during plat_trace_init() * Mirror console output via plat_trace_ext_puts() This enables crash log preservation for debugging production issues when debug builds are deployed. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>
Introduce an architecture-centric structure for Qualcomm platform configuration to improve scalability and maintainability. Chipsets are now grouped by architecture family (e.g., Kodiak and Lemans under HOYA). Configuration is split into three levels: 1. Platform-wide (conf.mk): Maps chipsets to architecture families 2. Architecture-level (hoya/arch.mk, hoya/arch_config.h): Base platform requirements common across all chipsets in the family (CPU, cores, TZDRAM, RAMBLUR, PRNG) 3. Chipset-specific (hoya/kodiak/target.mk, hoya/lemans/target.mk): Advanced features like clock drivers, diagnostic logging, and fuse provisioning The conf.mk uses variable-based includes to automatically load the correct architecture and chipset configurations, eliminating conditional logic from architecture files. This structure allows new chipsets to start with minimal base platform support and incrementally add advanced features. It also simplifies adding new architecture families in the future. No functional changes - pure refactoring with identical configuration values and hardware addresses. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>
ec87d72 to
2fad7a2
Compare
Add a driver for the Qualcomm Hardware Key Manager (HWKM), a hardware
IP block present on Qualcomm SoCs that manages cryptographic key slots
in a tamper-resistant key table. Keys stored in HWKM slots are never
exposed in plaintext to software above the security level they were
provisioned at; the hardware enforces per-slot access-control and
usage policies.
The driver exposes the following functionality to OP-TEE:
- Hardware Unique Key (HUK): implements tee_otp_get_hw_unique_key()
by deriving a device-unique key from the TZ UKDK L2 slot via the
SYSTEM_KDF command, using a fixed software context string and the
SWC BSVE binding. The derived key is cached in the driver context
after the first call.
- Full command set: NIST_KEYGEN, SYSTEM_KDF, KEY_WRAP_EXPORT,
KEY_UNWRAP_IMPORT, KEY_SLOT_CLEAR, KEY_SLOT_RDWR, and SET_TPKEY
are all implemented and exposed through a transaction queue API.
Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
b49020
reviewed
Jun 10, 2026
| #define PAS_ID_TURING 18 | ||
|
|
||
| #define HWKM_MASTER_BASE UL(0x010c0000) | ||
| #define HWKM_MASTER_SIZE UL(0x00020000) |
Member
There was a problem hiding this comment.
Since the base addresses seems to be common for Hoya architecture, can you rather move the defines to core/arch/arm/plat-qcom/hoya/arch_config.h?
Member
|
@qc-azarrabi please split this patch into 3 logical commits:
|
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.
This patch adds a new driver for the Qualcomm Hardware Key Manager (HWKM), a hardware IP block found on Qualcomm SoCs that provides hardware-enforced key storage and cryptographic key derivation.
Background
HWKM maintains a key table whose slots are never accessible in plaintext to software above the security level at which a key was provisioned. Each slot carries a hardware-enforced policy word that controls which operations, algorithms, and security domains may use it. The communicates with the hardware is through a command/response FIFO interface.
What this patch does
The driver implements the full HWKM command set:
Design notes
Commands are modelled as "transactions" - struct hwkm_transaction - that carry both the request and the response. Transactions are queued on a handle - struct hwkm_handle - and executed in FIFO order by hwkm_run_cmd_queue(). This makes multi-step sequences (e.g. clear + derive + read + clear for HUK derivation) easy to express.
Footnote
Only the KM_MASTER destination is currently supported. Slave instances (e.g. GPCE or ICE) can be added by extending hwkm_key_destination and run_transaction().