From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B3AB13C870E for ; Fri, 24 Jul 2026 09:13:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784884434; cv=none; b=CPVzpIwpsC9/v8ySMCH9Kq3yMohBICfzhGO+v5Lqllg/H6O/gxk5PQcjkP43X9nZpvJ0Fyv8SRnn1KPQDJD7Rl4YSCAN3d+hkR+AvBuXjGAeBS790Hn/MNcvzptXRos27WdRKetE1NAOSp0IpXOs/Oe4Gwv1ILUx1olTnc4yKNc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784884434; c=relaxed/simple; bh=w67qQqAdyi+Ybj6XnYCPF6f6f2EUvbXPSmE7iRSVj0E=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LvzvRxexzi3xkW8E1ONJGAoEaJvhihhz+cbSVatwkhB5PNgjwl2+b841xUWILZ/MtzdVxIlPLAZksDIhMHcUNNnOWSbWpHRWfhHLXQ7wmPMZAp6iG22EYXh1YHysN1PJDnEhao6U8A9OCod/zNCkUTi36CblYC93T8HIjAMqkL0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=cRa09QiH; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=Jz89CaYZ; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="cRa09QiH"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="Jz89CaYZ" Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66O4lFK53139553 for ; Fri, 24 Jul 2026 09:13:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= 9MgK1U5jSAS3Ah9+XNNPIqVUrC+U6xsLSHjHBFRHiBI=; b=cRa09QiHLf8wemDg G5YZe+SBLqeLUoCqmqNuF7HDcbtoyrxhYuvBu7qK8AXutKsr4CjD2UTfG/ISKy3J bAgYbsoC1zNhicR/kVK43UIruM5sCk0j4A8u7qt6n02u8vZZjdi5zMwHPBjxTldU uw0tE5AcNYMpaLwRhF9OyoCaZZKWmizvTlYFqRfPkntzyyTMkg6sBWg//twcl8Cq E2iJcsstAdYQwpG3Vz5bCpx+dx594Bip38RlRmKhXbz0elfYs6HKuoCfr3ZaTj5X RqHUOlcyJ/kLQF31tW0I2b5YklQB1ZkrMh54N1cYeV9W8c4YZXetPTYQKeMVH/bF y0tJ2Q== Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fkn9a3rc5-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 24 Jul 2026 09:13:51 +0000 (GMT) Received: by mail-pj1-f70.google.com with SMTP id 98e67ed59e1d1-38e63de75aaso357133a91.3 for ; Fri, 24 Jul 2026 02:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1784884431; x=1785489231; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:organization :from:content-language:references:cc:to:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=9MgK1U5jSAS3Ah9+XNNPIqVUrC+U6xsLSHjHBFRHiBI=; b=Jz89CaYZ8X3T5SGU6tBZPUqP447oIgzLduJELVdR+lwJEmNWWLlQqwI5OfJfuhkCeT PPKftGhpApfys5IuVgYKYxF+DPM+n58w0NdBGOwViZiTTZ7qLhhrgVwP9PIkmFKoBxhH CW2qvnuZZugTbb2gjIJSozOc9y2oqQ2A8D/42aVW1cm1Uhw+3W5JrpYrr5ZLvez1s52O E6UM+A1YRmvXY+tQE+kGKpHGgcHTu3/VAuWgwPgH2KZGlRgUagEqBX/yNdzJppblP85J AE4fvXnkVTKLK2R29407TQZjz7spAvPtVGduds+tAbPJ8UzJowLyZoJuZkYU8wQ/zNmE Djeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784884431; x=1785489231; h=content-transfer-encoding:content-type:in-reply-to:organization :from:content-language:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=9MgK1U5jSAS3Ah9+XNNPIqVUrC+U6xsLSHjHBFRHiBI=; b=Gyc+NzcHetSgxmboWFlmZtQMstVZ1k9ngCi5adZjiCEdPrsNfkKG2+2pc5QRIwzPsk Ix9CGv/W3q6dII2X+ScUbTtmz5/1n2bqrRGBtbn5IJnFvOfW0pa4dMIBQNcHNDFVZUn6 Bex2FaBNiodJyQLZcvZfGmnI61NMgjVPLJnV6ZZ8AqfTUkElhGNMqGxDL+WKHTsOc0KJ jKOh5DrjC1tG8Z6F3ZX8Q6PQaYxmUqXpRmtWUsBFZbK7EuspfmSnXyCfbrnfPjaRFyWR Q3eH+zanq9se+wGZGuqTKOGoWeRW9yIAhS26kIJA+DPFBjBd/Ylu8Bc6sSWJqkVBiJKs C0zQ== X-Forwarded-Encrypted: i=1; AHgh+RpN8F1zHhNtVH4I2OlpR8PfiBP7TaRIa4Do4VeUvNFsYBPAzG4GM3PEYiiKozuOkvPOSndaprwPUdWq8l4=@vger.kernel.org X-Gm-Message-State: AOJu0YxYlGAIw/BJCtcMuPl4JWnY6dYil9qC1hMlAT/Zp4zJrEjeSP8d Jt7xY1pPs89K8/Db4SaG5iCfWgxLo/ouAYpz1sGNb41L2L2UleQB9AuRsz5bG+jkDOx2rFTgU8f xV9VzUfOcAYkcJMS1LCBmz99llWk11Nzzf1dj/5GrHMCRikGIPD6noYsMJ/4i2iWaaWM= X-Gm-Gg: AR+sD12Kco8/AunkDVpPSR9S583lz55dqqbq9qA/W4WKb51PnJa+eUv2Q7pMZZvzi5V LY1eSV0hAShHbgg3Lrm//OlTsD0AOGURd+YMMMZtjqoBnbuM2N7ftEl1T77UPQ7dBlN8FnIaO2X PnmfsZsV71Awrr3ksV4qdKl78yjQxEXOBVsPGv+pt+rjZMCpnPDVnUpwSrgNkFgcrgkyg4z4qJ8 EQfunEJ/sNRETAnD9L4o9J/6gz8I36ftqHJHlkMH0Yx2w3u0Lj+51R2W9QwjMUgkejtdwUo8vXz SKTMxmmVRvcKkLRg7KbdWpBj3bIRZd52FbansvBUZPtJ8ZHbG4DnkmYrGZsb9wZPKR4+SlaNz3d IqQy5x1WY6apA0398kyZN/uDE5mQ= X-Received: by 2002:a17:90b:1643:b0:387:df8f:1408 with SMTP id 98e67ed59e1d1-38ec65ed975mr7199258a91.41.1784884430964; Fri, 24 Jul 2026 02:13:50 -0700 (PDT) X-Received: by 2002:a17:90b:1643:b0:387:df8f:1408 with SMTP id 98e67ed59e1d1-38ec65ed975mr7199216a91.41.1784884430398; Fri, 24 Jul 2026 02:13:50 -0700 (PDT) Received: from [10.92.203.75] ([202.46.23.19]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-38f08df8a94sm389306a91.2.2026.07.24.02.13.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Jul 2026 02:13:49 -0700 (PDT) Message-ID: Date: Fri, 24 Jul 2026 14:43:42 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/6] Add TEE based client driver for UEFI Secure Application To: Dmitry Baryshkov Cc: Jens Wiklander , Jens Wiklander , Sumit Garg , Amirreza Zarrabi , Bjorn Andersson , Konrad Dybcio , Basant Kumar , Apurupa Pattapu , Arun Kumar Neelakantam , op-tee@lists.trustedfirmware.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org References: <20260722-qcom_uefisecapp_migrate_qcomtee-v2-0-b8a8fcbe4211@oss.qualcomm.com> Content-Language: en-US From: Harshal Dev Organization: Qualcomm In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzI0MDA4MyBTYWx0ZWRfX7d8squ7FTfRd TAhgdGeWthFFSoAy3sUwmS1XqhfTag8FSRMnC+MR5/SNMmSTHOYBUTGOuV3WVR8aTu1vZjLykzg phWyc96BZcK7Zd67QHkfU92c0LnMrSSiXcl0yfWek1SPuJGSERfiCGA8yAL/b5nxbj4WjatfVLN PWdTJCF4KACC38Pz46B1tMz79JL9y4TrBPMTl4CxTY5IrYjBR3Cx/2RuhFmf/5/1noaSpot/pvf 0j2yrU/MFHsyH5Cp82q1/EdoI7CyyccK2oo9YJBwMFL+rrt30qeEnWJvEm3/uqy9+Oeth96yDfC Bw30h5dDBkoU2gbi02iAmfHms14UMMMvpTLj+u8jSfK7gIscu7sV0VYM0hyIoZ4k0/iaRVBZXAi tAhOgqvydic9Y2HlzXiOQlT/J8uPGjbjWD4JMEQbIMwFg/+3axP3CZheTqnxp+sEil5QNWcuBEk i7SIIGt+rhAKWgQDV0g== X-Proofpoint-ORIG-GUID: hRsVlW5F_6kYCriMXWPDxHT5uac2E1_A X-Proofpoint-GUID: hRsVlW5F_6kYCriMXWPDxHT5uac2E1_A X-Authority-Analysis: v=2.4 cv=WOdPmHsR c=1 sm=1 tr=0 ts=6a632ccf cx=c_pps a=0uOsjrqzRL749jD1oC5vDA==:117 a=j4ogTh8yFefVWWEFDRgCtg==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=eoimf2acIAo5FJnRuUoq:22 a=P-IC7800AAAA:8 a=NEAV23lmAAAA:8 a=EPKcpx9xAAAA:20 a=EUspDBNiAAAA:8 a=VwQbUJbxAAAA:8 a=EQysn5-VQ2r5Ey136RIA:9 a=QEXdDO2ut3YA:10 a=mQ_c8vxmzFEMiUWkPHU9:22 a=d3PnA9EDa4IxuAV0gXij:22 a=ZT_8zCgGubuJgGonBfBE:22 X-Proofpoint-Spam-Info: AW1haW4tMjYwNzI0MDA4MyBTYWx0ZWRfX+Df28D3dz2Ry JUDqfYwlffv3+m52lkZPxjamKGvmpXYq0sdZZzrriyvN6uLP/39NzvlAFcrI8NUps//t+tHd6xn eX6UvZbXEHj5CLjVLn4X6jZHnlYd6eE= X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-24_01,2026-07-22_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 malwarescore=0 suspectscore=0 lowpriorityscore=0 adultscore=0 clxscore=1015 impostorscore=0 bulkscore=0 priorityscore=1501 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607240083 Hi Dmitry, On 22-07-2026 01:56 pm, Dmitry Baryshkov wrote: > On Wed, Jul 22, 2026 at 12:29:11PM +0530, Harshal Dev wrote: >> On Qualcomm SoC based platforms, UEFI stores EFI variables within the >> Replay Protected Memory Block (RPMB) which is only accessible by the >> Qualcomm Trusted Execution Environment (QTEE). > > Is it so? I think RPMB is accessible to Linux... I should have been more descriptive here, RPMB is accessible by Linux but its frames can only be prepared by QTEE. 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 a TEE. So on Qualcomm platforms (and many others platforms with a TEE) Linux can only route the RPMB frames generated by QTEE to the storage, it cannot create and write the RPMB frames itself (it doesn't have access to the key). While it is possible for Linux to generate/program/store this key, on Qualcomm platforms we do not want Linux to do so because we do not trust it. We trust QTEE. I will re-phrase this and make it a bit more clear everywhere. > >> For Qualcomm platforms without emulated RPMB support, specifically > > What is emulated RPMB support? Why is it mentioned here? Which platforms > use emulated RPMB? Emulated RPMB refers to RPMB on a storage which doesn't have its own firmware. Primarily, NAND/NOR storage. Unlike UFS/eMMC storage, NAND/NOR storage does not have a storage controller where we can program the RPMB key to be used by the firmware. So we must 'emulate' RPMB by moving the storage driver within QTEE and making the driver hold/use the key. Qualcomm compute SoCs (Glymur, Hamoa) have RPMB available on SPI-*NOR* storage, and a driver for communicating with it is also available in QTEE. And so, these have 'emulated' RPMB. I will add this detail in an updated cover letter. > >> platforms where RPMB is not located within SPI-NOR storage and instead >> located on UFS/EMMC storage, non-volatile EFI variables can only be set via >> a callback request from the UEFI Secure Application to the RPMB service >> running in user-space (within the QTEE supplicant [1]). > > Can it be moved to the kernel? We have a plan to move the RPMB service to the kernel similar to OPTEE: https://elixir.bootlin.com/linux/v7.2-rc3/source/drivers/tee/optee/rpc.c#L449 It is a work in progress. Once this happens, we don't need QTEE supplicant available on the Linux distribution. > >> >> Unlike the QCOM-TEE driver, the QSEECOM driver (used by the current >> QSEECOM based uefisecapp) does not support callback requests. > > How did it work then? I think Windows has been perfectly using QSEECOM > rather than QTEE. It works because Windows on Arm on Qualcomm has SPI-NOR storage. A driver for which is available within QTEE, and so QTEE does not need to make a callback request to Linux to request RPMB frame routing. However, in case of UFS/eMMC storage the driver only exists in the Linux kernel and so QTEE must make a callback request. And so, if you try to use the QSEECOM driver to write EFI-variables to RPMB on a device with UFS/eMMC storage, it won't work. > >> And on >> certain Qualcomm platforms such as the RB3Gen2, attempts to access the >> QSEECOM interface fail due to lack of support within Qualcomm TEE. > > So, I assume, on RB3 Gen2 the QSEECOM doesn't report uefisecapp as > supported. Does it? It doesn't, this API returns -2 if I add RB3 Gen2 in the allow-list for QSEECOM: https://elixir.bootlin.com/linux/v7.2-rc3/source/drivers/firmware/qcom/qcom_qseecom.c#L46 > >> On these platforms, a TEE based uefisecapp client driver is required to: >> 1. Access cached & volatile EFI variables stored in uefisecapp's memory. >> 2. Ensure persistence of non-volatile EFI variables via writes through >> the RPMB service hosted in the QTEE supplicant. >> >> 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 this support. > > What about existing WoA devices? New Windows on Arm devices like Hamoa/Glymur work perfectly fine with existing QSEECOM based uefisecapp. But they will also work with this new QCOMTEE based uefisecapp once they upgrade their firmware. I need to double-check but this firmware release for Glymur on Qualcomm Linux is probably carrying the support for QCOMTEE based uefisecapp access: https://github.com/qualcomm-linux/meta-qcom/commit/728251fcbe5113980805ea6c571e33235062ee71 If not, the next release will definitely have it since I have merged support for this in QTEE and talked to the boot firmware release team about this. The next planned firmware upgrade for Hamoa will also provide this support for Qualcomm Linux. And similarly, for all other targets being supported upstream. > >> >> 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. > > Can it be fixed instead of having static lists? In the end, we can't > guarantee that users update the firmware. > Unfortunately, no existing QTEE release out there currently has this support. But support for this is currently being added by QTEE team last I checked with them. Once it is available, and a new QTEE firmware release is out there, we will add support for dynamically querying QTEE services in the QCOMTEE driver. >> >> 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. > > What about fused devices? The procedure for updating the firmware on fused devices is slightly different. The firmware images need to be signed by the OEM using the security profile of the chipset before flashing/upgrading them. Security profiles are now public: https://github.com/qualcomm/security-profiles Regards, Harshal > >> >> 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. >> >> 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_variables_using_efivar_tool.html >> >> Signed-off-by: Harshal Dev >> --- >> 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-f659cbd5d04c@oss.qualcomm.com >> >> --- >> 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 | 7 + >> drivers/firmware/qcom/Kconfig | 24 ++ >> drivers/firmware/qcom/Makefile | 1 + >> drivers/firmware/qcom/qcom_tee_uefisecapp.c | 525 ++++++++++++++++++++++++++++ >> drivers/firmware/qcom/qcom_tee_uefisecapp.h | 120 +++++++ > > I don't see any changes to the QSEECOM drivers. Is it allowed to use > QSEECOM and QTEE access to uefisecapp at the same time? > >> drivers/tee/qcomtee/call.c | 205 ++++++++++- >> 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(+), 33 deletions(-) >> --- >> base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e >> change-id: 20260408-qcom_uefisecapp_migrate_qcomtee-13869d45e014 >> >> Best regards, >> -- >> Harshal Dev >> >