- OP-TEE - lists.trustedfirmware.org

Re: [PATCH v2 0/3] Add TPM support via Qualcomm TEE TPM TA

by zeroknots

Hi Kuldeep, A data point from retail hardware, in case it is useful for this series: on an ASUS Zenbook A14 UX3407NA (Glymur, X2E-88-100, BIOS UX3407NA.315) the TPM TA is not reachable as QTEE service 81, but it is present as the QSEECOM application "qcom.tz.tpm". With the qcomtee driver on a 7.3-rc3 based kernel, QTEE reports version 5.2.0, and service discovery finds neither 81 (TPM) nor 413 (UEFI secure app). On the same boot, qseecom (version 0x1402000) works and backs efivars through "qcom.tz.uefisecapp" (app id 7). An app-id lookup for "qcom.tz.tpm" returns app id 1; a made-up name returns -ENOENT. The Windows driver for this machine agrees: QcTrEE8480.inf configures the TPM service with AppName="qcom.tz.tpm", SecureApp=1, LoadApp=0 (preloaded by firmware). The EFI configuration table carries the TPMEventLog and TPMFinalLog entries, so the firmware TPM is active. Through that app, using a QSEECOM transport (based on Xilin Wu's out-of-tree SC8280XP driver: QUERY_INFO_2 / SEND_COMMAND with a CRB-style control area, here at 0x81d10000), /dev/tpm0 works: TPM 2.0, manufacturer QCOM, vendor string "xCG fTPM", firmware 0x40000, real PCR 0-7 values, GetRandom, ECC and RSA-2048 primaries, sign and verify, and a sealed object that persists across reboots. So, as far as I can tell, retail Glymur laptops may ship firmware on which this driver finds no TPM, while the same TA is available over QSEECOM. The same applies to the prerequisite series that moves uefisecapp to QCOMTEE [1]: on this firmware service 413 is absent and EFI variables work only through the QSEECOM uefisecapp. If the QSEECOM path were dropped for Glymur, efivars would stop working on this machine, so it would be good to keep it as a fallback when the QTEE service is not found. Two questions: - Is service 81 expected to appear on retail firmware through an update, or is it specific to the CRD firmware? - Would you consider a QSEECOM-based path for such firmware? I am happy to test this series, or any other service UID you would like checked, on this machine, and to share the transport code. [1] https://lore.kernel.org/lkml/20260722-qcom_uefisecapp_migrate_qcomtee-v2-0-… Thanks, zeroknots Assisted-by: LLM (analysis and drafting; the measurements were made on the hardware and reviewed by me)

1 month

4
4
0 0

[PATCH v2 0/3] Add TPM support via Qualcomm TEE TPM TA

by Kuldeep Singh

Qualcomm platforms with a discrete TPM (dTPM) talked to it directly over a non-secure SPI channel from the kernel. Arm's Base Boot Security Requirements (BBSR) v1.4 require that access to go through TrustZone instead, so on affected Qualcomm platforms the TPM 2.0 instance is now fronted by a Trusted Application (TA) running inside Qualcomm's Trusted Execution Environment (QTEE), which talks to the dTPM (or implements an fTPM) on the kernel's behalf. This series adds a kernel driver for that TA, built on the QCOMTEE object-IPC transport (drivers/tee/qcomtee/) already used to reach other QTEE services. This patch series functionally depends on below(patch 5/6 specifically) for qtee service discovery. - https://lore.kernel.org/lkml/20260722-qcom_uefisecapp_migrate_qcomtee-v2-0-… Tested on Glymur-crd target with tpm2-tools utility. Validations: - Get capabilities - Random number generator - RSA key creation, encryption and decryption. Signed-off-by: Kuldeep Singh <kuldeep.singh(a)oss.qualcomm.com> --- Changes in v2: - Use QCOMTEE_TPM_UID as 81 for service discovery in patch 1. - Use FIELD_GET, zero initialised array and log improvement (Konrad) - Improve commit title and other fixes (Jarkko) - Split MAINTAINERS entry as separate patch. - Link to v1: https://patch.msgid.link/20260831-tpm_qcom_driver-v1-0-6f16fa6924fa@oss.qua… To: Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com> To: Jens Wiklander <jenswi(a)kernel.org> To: Sumit Garg <sumit.garg(a)kernel.org> To: Peter Huewe <peterhuewe(a)gmx.de> To: Jarkko Sakkinen <jarkko(a)kernel.org> To: Jason Gunthorpe <jgg(a)ziepe.ca> To: Kuldeep Singh <kuldeep.singh(a)oss.qualcomm.com> Cc: linux-arm-msm(a)vger.kernel.org Cc: op-tee(a)lists.trustedfirmware.org Cc: linux-kernel(a)vger.kernel.org Cc: linux-integrity(a)vger.kernel.org --- Kuldeep Singh (3): tee: qcomtee: Register qcom.tz.tpm service for discovery tpm: Introduce Qualcomm TPM driver MAINTAINERS: Add Qualcomm TPM driver entry MAINTAINERS | 7 + drivers/char/tpm/Kconfig | 9 + drivers/char/tpm/Makefile | 1 + drivers/char/tpm/tpm_qcom.c | 354 ++++++++++++++++++++++++++++++++++++++ drivers/char/tpm/tpm_qcom.h | 83 +++++++++ drivers/tee/qcomtee/call.c | 4 +- drivers/tee/qcomtee/qcomtee_msg.h | 2 + 7 files changed, 459 insertions(+), 1 deletion(-) --- base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e change-id: 20260831-tpm_qcom_driver-d21c720e73b2 prerequisite-change-id: 20260408-qcom_uefisecapp_migrate_qcomtee-13869d45e014:v2 prerequisite-patch-id: 4dc81445c9baf36f420da8c2e2bed96e71b31a5b prerequisite-patch-id: b487dfe2fbc076f4815dc6c73b9e68b0b78c961f prerequisite-patch-id: c5df2b3696520a96f95b2d3535ed84cdc21cc315 prerequisite-patch-id: bbdd5327c15aeaa99ce9b74bab324a98f084ed48 prerequisite-patch-id: 07d9c4e9fe9fd61f60e3f35b30b9d81716f0734c prerequisite-patch-id: 10ff88d87586f21f3cff3f72dbd21c27adbfbbcc Best regards, -- Kuldeep Singh <kuldeep.singh(a)oss.qualcomm.com>

1 month

4
16
0 0

[PATCH v3 0/6] Add TEE based client driver for UEFI Secure Application

by Harshal Dev

On Qualcomm SoC based platforms, UEFI stores EFI variables within the Replay Protected Memory Block (RPMB) located within either the UFS, eMMC or SPI-NOR storage. The RPMB key which is one-time programmed into the storage controller to allow authentication of the RPMB frames is generated by and only available to the Qualcomm Trusted Execution Environment (QTEE). Thus, only QTEE can prepare the RPMB frames which will be accepted by the storage controller. The legacy QSEECOM protocol used for communicating with the QTEE is deprecated and replaced with the use-case agnostic SMCInvoke protocol starting with the Qualcomm SM8x50 series. On platforms where the QSEECOM protocol still works (the QSEECOM driver probes) the driver does not support a listener interface with QTEE to enable writing of non-volatile EFI variables (via listener requests to Linux from QTEE) to the RPMB for UFS and eMMC storage. (Qualcomm Compute platforms with SPI-NOR storage are an exception to this and work with QSEECOM, see the NOTE below) Therefore on such platforms, a TEE client driver (which communicates with QTEE via the SMCInvoke protocol implemented by the QCOMTEE driver registered with the TEE subsystem) must be used to update such EFI variables through the RPMB service hosted in the QTEE supplicant user-space daemon [1] which forwards RPMB packets to the RPMB device. This series introduces such a uefisecapp TEE client driver for the aforementioned Qualcomm platforms which installs efi-var operations _if_ the QCOMTEE driver registers support for an object-IPC based uefisecapp service on the TEE bus during its probe. Only new QTEE firmware versions available at [2] provide access to the uefisecapp service via the SMCInvoke protocol. Thus, QCOMTEE now maintains a static list of always-available object-IPC based secure services exposed by QTEE. These services are implemented either within the QTEE kernel or within a pre-loaded Trusted Application (TA) usually loaded by the bootloader. The uefisecapp TA is an example of a preloaded TA loaded by UEFI. A static list is required since QTEE does not yet expose any way to dynamically query and enumerate the services exposed by it. To facilitate object-IPC interactions from the kernel-space, this series also introduces a tee_client_object_invoke_func() to allow invocation of TEE objects similar to the existing tee_client_invoke_func() API exported by the TEE subsystem which allows invocation of TEE functions. Some suporting changes are also introduced to track and handle operations for TEE contexts opened from the kernel-space in the back-end QCOM-TEE driver. Finally and as previously mentioned, access to the object-IPC based uefisecapp service is restricted on older QTEE firmware versions. A new QTEE firmware release must be picked up from QArtifactory [2] for all upstream supported Qualcomm SoCs to enable access to uefisecapp service via the TEE client driver. This patch series has been validated on Kodiak RB3Gen2 platform with UFS storage by attempting to read/write EFI variables via the efivar tool [3] after mounting the efivarfs filesystem. See [4] for an example. NOTE: Since Compute platforms do not have a firmware running on their SPI-NOR storage controller which must be programmed with a RPMB key, QTEE has a SPI-NOR driver which holds the key, and so the QSEECOM driver can be used for updating EFI variables on these platforms because QTEE never makes a listener request to Linux (QTEE doesn't need the Linux SPI-NOR driver). Such platforms are outlined in the following static list [5]. Merge Strategy: This patch series could either be taken from the OP-TEE tree or the QCOM soc tree. I would prefer it to be picked by the OP-TEE tree since all except the uefisecapp TEE client driver patch in this series make changes relevant to the TEE subsystem. It would be great if the QCOM soc tree maintainers can Ack the uefisecapp driver patch. [1] https://github.com/qualcomm/minkipc [2] https://shorturl.at/zQU07 [3] https://github.com/rhboot/efivar [4] https://docs.qualcomm.com/doc/80-70020-27/topic/manage_uefi_environment_var… [5] https://elixir.bootlin.com/linux/v7.3-rc5/source/drivers/firmware/qcom/qcom… Signed-off-by: Harshal Dev <harshal.dev(a)oss.qualcomm.com> --- Changes in v3: - Updated the cover letter and commit messages to highlight the following: 1. Only QTEE has the ability to prepare RPMB frames since it generates and holds the RPMB key. 2. The QSEECOM protocol is deprecated on new platforms and so this series migrates the uefisecapp to SMCInvoke which is a use-case agnostic, transport focused and easier to maintain protocol. - Use single if statement to update both flags and addr/uaddr. - Remove redundant use of new error variable in qcomtee_get_qtee_feature_list(). - Minor fixes such as concise error prints and use of better error codes. - Fix a double free in qtee_enumerate_service(). - Re-org the qcomtee_enumerate_services() function to re-use the same oic and client_env object. - Remove depends on !QCOM_QSEECOM_UEFISECAPP from Kconfig since both drivers can co-exist even on platforms that support both QSEECOM and SMCInvoke protocols. - Update the Kconfig description to better help the user understand when to enable the TEE based uefisecapp driver. - Removed qcom_tee_uefisecapp.h file and inline the header in qcom_tee_uefisecapp.c - Rebased patch series onto the latest linux next tag: next-20260930. - Link to v2: https://lore.kernel.org/r/20260722-qcom_uefisecapp_migrate_qcomtee-v2-0-b8a… Changes in v2: - Drop using MSB of the object_id to distingush kernel and user object invoke contexts. - Introduce enum tee_object_invoke_origin to check the context of object invocation. - Link to v1: https://lore.kernel.org/r/20260707-qcom_uefisecapp_migrate_qcomtee-v1-0-f65… --- Amirreza Zarrabi (2): tee: Add kernel client object invoke helper tee: qcomtee: Allow object invokes from kernel clients Harshal Dev (4): tee: qcomtee: Track the object invocation context tee: Export uuidv5 generation for TEE backends tee: qcomtee: Add support for registering QTEE services on TEE bus firmware: qcom: Add support for TEE based EFI-var client driver MAINTAINERS | 6 + arch/arm64/configs/defconfig | 1 + drivers/firmware/qcom/Kconfig | 31 ++ drivers/firmware/qcom/Makefile | 1 + drivers/firmware/qcom/qcom_tee_uefisecapp.c | 636 ++++++++++++++++++++++++++++ drivers/tee/qcomtee/call.c | 206 ++++++++- drivers/tee/qcomtee/core.c | 9 +- drivers/tee/qcomtee/qcomtee.h | 12 + drivers/tee/qcomtee/qcomtee_msg.h | 1 + drivers/tee/qcomtee/qcomtee_object.h | 16 +- drivers/tee/tee_core.c | 24 +- include/linux/tee_core.h | 23 +- include/linux/tee_drv.h | 18 +- 13 files changed, 952 insertions(+), 32 deletions(-) --- base-commit: 6c2cb8b8b843d216ab549b678a0d8831c43153e0 change-id: 20260408-qcom_uefisecapp_migrate_qcomtee-13869d45e014 Best regards, -- Harshal Dev <harshal.dev(a)oss.qualcomm.com>

1 month

3
14
0 0

[GIT PULL] TEE QTEE fix for v7.3

by Jens Wiklander

Hello soc maintainers, Please pull this small kernel-doc fix for the QTEE driver in the TEE subsystem. Thanks, Jens The following changes since commit 8d3ae59288f1e7d58d76558a6ee96d533bc5019f: Linux 7.2 (2026-08-16 14:32:26 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/qcomtee-fix-for-v7.3 for you to fetch changes up to 93847823b6761e1791a7db10f55bbd4f79fa0dbc: tee: qcomtee: fix kernel-doc warnings (2026-08-24 14:49:01 +0200) ---------------------------------------------------------------- Fix kernel-doc warnings ---------------------------------------------------------------- Babanpreet Singh (1): tee: qcomtee: fix kernel-doc warnings drivers/tee/qcomtee/async.c | 4 ++-- drivers/tee/qcomtee/qcomtee_msg.h | 2 +- drivers/tee/qcomtee/qcomtee_object.h | 1 + 3 files changed, 4 insertions(+), 3 deletions(-)

1 month

1
0
0 0

[GIT PULL] TEE QTEE update for v7.4

by Jens Wiklander

Hello soc maintainers, Please pull this small patch for the QTEE driver in TEE subsystem. Thanks, Jens The following changes since commit 8d3ae59288f1e7d58d76558a6ee96d533bc5019f: Linux 7.2 (2026-08-16 14:32:26 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/qcomtee-for-v7.4 for you to fetch changes up to 615970476444bdf853c7c3ecdbe809dbdca06c16: tee: qcomtee: Drop unused assignment of platform_device_id driver data (2026-09-16 10:38:46 +0200) ---------------------------------------------------------------- Drop unused assignment of platform_device_id driver data ---------------------------------------------------------------- Uwe Kleine-König (The Capable Hub) (1): tee: qcomtee: Drop unused assignment of platform_device_id driver data drivers/tee/qcomtee/call.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)

1 month

1
0
0 0

[GIT PULL] TEE updates for v7.4

by Jens Wiklander

Hello soc maintainers, Please pull this small patch for the TEE subsystem. Thanks, Jens The following changes since commit 8d3ae59288f1e7d58d76558a6ee96d533bc5019f: Linux 7.2 (2026-08-16 14:32:26 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/tee-for-v7.4 for you to fetch changes up to 6229fda9a88656ea7c727c3e2401080c5d3efbc6: tee: move tee_ioctl_shm_register_data to above IOCTL definition (2026-09-16 07:52:31 +0200) ---------------------------------------------------------------- Move tee_ioctl_shm_register_data to above IOCTL definition ---------------------------------------------------------------- Andrew Davis (1): tee: move tee_ioctl_shm_register_data to above IOCTL definition include/uapi/linux/tee.h | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-)

1 month

1
0
0 0

[GIT PULL] OP-TEE fixes for v7.3

by Jens Wiklander

Hello soc maintainers, Please pull these fixes for the OP-TEE driver in the TEE subsystem. Thanks, Jens The following changes since commit 8d3ae59288f1e7d58d76558a6ee96d533bc5019f: Linux 7.2 (2026-08-16 14:32:26 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/optee-fixes-for-v7.3 for you to fetch changes up to 3c0d2f1f431c51a11253f28763be723ac782fd7a: tee: optee: ffa: support shared memory offsets on large-page kernels (2026-10-02 16:08:05 +0200) ---------------------------------------------------------------- OP-TEE fixes for v7.3 - Register the TEE devices only once fully initialized - Support FF-A shared memory offsets on large-page kernels ---------------------------------------------------------------- Mahantesh Salimath (1): tee: optee: ffa: support shared memory offsets on large-page kernels Shao-Fu Chen (1): optee: register TEE devices only once fully initialized drivers/tee/optee/ffa_abi.c | 38 ++++++++++++++++++++++++++------------ drivers/tee/optee/optee_msg.h | 4 ++-- drivers/tee/optee/smc_abi.c | 17 ++++++++--------- 3 files changed, 36 insertions(+), 23 deletions(-)

1 month

2
4
0 0

Preparing for OP-TEE 4.11.0

by Jens Wiklander

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE version 4.11.0 is now scheduled for release on 2026-10-16. So, now is a good time to start testing the master branch across various platforms and report or fix any bugs. The GitHub pull request for collecting Tested-by tags or any other comments is https://github.com/OP-TEE/optee_os/pull/8054. We will create the release candidate tag 4.11.0-rc1 next Friday, October 2. You can find more information related to releases here: https://optee.readthedocs.io/en/latest/general/releases.html Thanks, Jens

1 month

1
1
0 0

[PATCH] tee: optee: ffa: support shared memory offsets on large-page kernels

by Mahantesh Salimath

OP-TEE FF-A memory objects use 4 KiB pages, while the kernel page size may be larger. Consequently, tee_shm->offset can be greater than or equal to FFA_PAGE_SIZE, but OP-TEE rejects such a value in internal_offs. Do not encode the excess page offset in offs_low/offs_high. Those fields describe the logical memref offset and are copied back into tee_param->shm_offs on return. Folding the page offset into them breaks parameter round trips when a memref is reused. They are also ignored by the OPTEE_RPC_CMD_SHM_ALLOC response path, which uses only global_id and internal_offs to construct the shared-memory mobj. Instead, start the FF-A descriptor at the 4 KiB page containing the shared buffer, the same approach as optee_fill_pages_list() in the SMC ABI. Store the remaining in-page offset in internal_offs and preserve shm_offs in offs_low/offs_high. This keeps internal_offs within the FF-A page size, maps RPC allocations at the correct address, and preserves normal memref offsets across repeated invocations. Tested on ARMv8-A with 64 KiB PAGE_SIZE. OP-TEE OS ran as a secure partition under Hafnium (SPMC) over FF-A. Verified registered shared memory with tee_shm->offset >= 4 KiB, memref reuse on the same TEEC_Operation, and RPC OPTEE_RPC_CMD_SHM_ALLOC (xtest regression 6007-6009). optee_hello_world, optee_aes, and xtest regression 1005, 1007, 1008, 4001-4003 and 6001-6003 also passed. Fixes: 4615e5a34b95 ("optee: add FF-A support") Acked-by: Liming Sun <limings(a)nvidia.com> Acked-by: James Hurley <jahurley(a)nvidia.com> Acked-by: Dave Thompson <davthompson(a)nvidia.com> Signed-off-by: Mahantesh Salimath <mahantesh(a)nvidia.com> --- drivers/tee/optee/ffa_abi.c | 66 +++++++++++++++++++++++++++++------ drivers/tee/optee/optee_msg.h | 4 +-- 2 files changed, 57 insertions(+), 13 deletions(-) diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c index 633715b98625..2a37e4899dc6 100644 --- a/drivers/tee/optee/ffa_abi.c +++ b/drivers/tee/optee/ffa_abi.c @@ -187,6 +187,40 @@ static int optee_ffa_from_msg_param(struct optee *optee, return 0; } +/* + * OP-TEE FF-A memory objects use 4 KiB pages while the kernel page size may + * be larger, for example 64 KiB on arm64. The FF-A descriptor is registered + * from the 4 KiB page containing the start of the shared buffer, so + * internal_offs is the offset into that page. + */ +static void optee_ffa_set_internal_offs(struct optee_msg_param_fmem *fmem, + struct tee_shm *shm) +{ + size_t page_offs = tee_shm_get_page_offset(shm); + + BUILD_BUG_ON(PAGE_SIZE < FFA_PAGE_SIZE); + + fmem->internal_offs = page_offs & (FFA_PAGE_SIZE - 1); +} + +/* + * Keep shm_offs unchanged in offs_low/offs_high: it is returned to callers + * and may be reused for a subsequent invocation. + */ +static int optee_ffa_set_fmem_offsets(struct optee_msg_param_fmem *fmem, + struct tee_shm *shm, u64 shm_offs) +{ + optee_ffa_set_internal_offs(fmem, shm); + + fmem->offs_low = shm_offs; + fmem->offs_high = shm_offs >> 32; + /* Check that the entire offset could be stored. */ + if (fmem->offs_high != shm_offs >> 32) + return -EINVAL; + + return 0; +} + static int to_msg_param_ffa_mem(struct optee_msg_param *mp, const struct tee_param *p) { @@ -196,14 +230,8 @@ static int to_msg_param_ffa_mem(struct optee_msg_param *mp, TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT; if (shm) { - u64 shm_offs = p->u.memref.shm_offs; - - mp->u.fmem.internal_offs = shm->offset; - - mp->u.fmem.offs_low = shm_offs; - mp->u.fmem.offs_high = shm_offs >> 32; - /* Check that the entire offset could be stored. */ - if (mp->u.fmem.offs_high != shm_offs >> 32) + if (optee_ffa_set_fmem_offsets(&mp->u.fmem, shm, + p->u.memref.shm_offs)) return -EINVAL; mp->u.fmem.global_id = shm->sec_world_id; @@ -284,14 +312,30 @@ static int optee_ffa_shm_register(struct tee_context *ctx, struct tee_shm *shm, .nattrs = 1, }; struct sg_table sgt; + size_t page_offs; + size_t ffa_offs; + size_t ffa_size; int rc; + if (!num_pages) + return -EINVAL; + rc = optee_check_mem_type(start, num_pages); if (rc) return rc; - rc = sg_alloc_table_from_pages(&sgt, pages, num_pages, 0, - num_pages * PAGE_SIZE, GFP_KERNEL); + page_offs = tee_shm_get_page_offset(shm); + ffa_offs = round_down(page_offs, FFA_PAGE_SIZE); + ffa_size = num_pages * PAGE_SIZE - ffa_offs; + + /* + * Start the FF-A descriptor at the 4 KiB page containing the shared + * buffer, skipping unused leading 4 KiB pages when PAGE_SIZE is + * larger. Same approach as optee_fill_pages_list() in the SMC ABI. + * This leaves only page_offs & (FFA_PAGE_SIZE - 1) for internal_offs. + */ + rc = sg_alloc_table_from_pages(&sgt, pages, num_pages, ffa_offs, + ffa_size, GFP_KERNEL); if (rc) return rc; args.sg = sgt.sgl; @@ -458,8 +502,8 @@ static void handle_ffa_rpc_func_cmd_shm_alloc(struct tee_context *ctx, .attr = OPTEE_MSG_ATTR_TYPE_FMEM_OUTPUT, .u.fmem.size = tee_shm_get_size(shm), .u.fmem.global_id = shm->sec_world_id, - .u.fmem.internal_offs = shm->offset, }; + optee_ffa_set_internal_offs(&arg->params[0].u.fmem, shm); arg->ret = TEEC_SUCCESS; } diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 7d9b12e71c03..6c3043f8da33 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -136,8 +136,8 @@ struct optee_msg_param_rmem { * struct optee_msg_param_fmem - FF-A memory reference parameter * @offs_low: lower bits of offset into shared memory reference * @offs_high: higher bits of offset into shared memory reference - * @internal_offs: internal offset into the first page of shared memory - * reference + * @internal_offs: offset into the first 4 KiB page of the FF-A shared + * memory region * @size: size of the buffer * @global_id: global identifier of the shared memory */ -- 2.43.0

1 month

3
5
0 0

[PATCH] tee: shm: reject zero-sized allocations in tee_dyn_shm_alloc_helper()

by Georgiy Osokin

tee_dyn_shm_alloc_helper() derives nr_pages from a caller-supplied size and passes it to alloc_pages_exact() without checking it. For size == 0 nr_pages is 0, and alloc_pages_exact(0) calls get_order(0), which is documented as undefined and returns BITS_PER_LONG - PAGE_SHIFT. The page allocator then trips its order > MAX_PAGE_ORDER warning and fails the allocation; on a panic_on_warn kernel that ends the boot. This can be triggered by TEE_IOC_SHM_ALLOC with struct tee_ioctl_shm_alloc_data where size is 0. Reject a zero page count, as register_shm_helper() already does for the register path. Fixes: cf4441503e20 ("tee: optee: Move pool_op helper functions") Cc: stable(a)vger.kernel.org Cc: lvc-project(a)linuxtesting.org Signed-off-by: Georgiy Osokin <g.osokin(a)auroraos.dev> --- drivers/tee/tee_shm.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index 6742b3579..daa4af1e0 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -343,6 +343,10 @@ int tee_dyn_shm_alloc_helper(struct tee_shm *shm, size_t size, size_t align, unsigned int i; int rc = 0; + /* get_order(0) is undefined and exceeds MAX_PAGE_ORDER. */ + if (!nr_pages) + return -EINVAL; + /* * Ignore alignment since this is already going to be page aligned * and there's no need for any larger alignment. base-commit: 72d3fcf802c45d00b300f25b848a93c3a2bd7c7e -- 2.54.0

1 month

3
2
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE