From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.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 EAE7F388E7D for ; Mon, 20 Jul 2026 10:19:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784542757; cv=none; b=O4u8ogvbrzrze2WW+ixpl1KtoaL58nkAv1urkp/xcxmMZBq/1a36QK/h8fTTST9MQHgn1FIWBDq87jT46j7+xAFOQq17prXPbc3+0kkzx+AEDz5f3EFHU6k5JHj7ueZOnxus6njkcPPvJ+9QPz99aiUy8mZd4WPKDdcOzeVjjgE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784542757; c=relaxed/simple; bh=yapMXRgqm8On8wZD3Y13ylERRbelSnvEypyi9xq1P1o=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=hyrOS9b3LR8aNXnPxOG3PHbry8vwdVY0ahk2kMXjzVoOlev7t+Euv8ruOA7bMkhwmXIbchIiaRO57XgbctChA64vsdK6ful8lbP1flKa2aeN9TdGAEWBYiOpv5R0a2XJcskwWN4UYXPt1tRq/3o42ZOshTxjOYLx9YLha20xuwg= 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=owE2yGJg; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=YoAwbrDh; arc=none smtp.client-ip=205.220.180.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="owE2yGJg"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="YoAwbrDh" Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66K9vfmC2045730 for ; Mon, 20 Jul 2026 10:19:14 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= O+rneuRae7ccfS7HwBJRtw/KkE2FTct/JS+yPwRVhak=; b=owE2yGJgCDL0e0En 11/827nlFwSyoMVkyXId2i4zHXzT0Rf5rJUYShV2M4/LGzssxtqJLRGjiLnPGK/z G1A0ZzgeAmoCycgIbzVQIwdgYKDGDgQWkb7MTCE3Gt6oCr4FXdOeSEi5rVUyYyEp eSGutiGYPBnllu0kcb9cQTAzwivea/VR8k8eBzixtDc/zFOQXo0wFFWXzyovrofl fQ3DK7Ei6yWqwTyM/2LVcqTTEED5aX/uhmvd/QcR7rzQTlEOTecwecST/pei+wdD 5DHDsJ/G65aGOUPiQhIN8gPaAIYSTXuu9wD3zbjGVobquIjorBqKl7Z7Qx+21lsf SzOvUQ== Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fhggg8g8u-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 20 Jul 2026 10:19:14 +0000 (GMT) Received: by mail-pf1-f200.google.com with SMTP id d2e1a72fcca58-84a651759a2so12313020b3a.3 for ; Mon, 20 Jul 2026 03:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1784542754; x=1785147554; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:organization :content-language:references:cc:to:subject:from:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to:content-type; bh=O+rneuRae7ccfS7HwBJRtw/KkE2FTct/JS+yPwRVhak=; b=YoAwbrDhOoBwNu/6rRjnIGiFTdbsvGFqxI7KKzTPMPqvxeWy5JJztrBNcXHzjoTfs9 0DvhGNyXsBHWV8HLWc1hu2X4rtDjtN8wD1eNB1lXYBiOTSK/E16W2VrNLN3dm9BUcJdr VyK47TFmakIMPCWWS6IZUDD1xRYtVVkU9NOAjLIL/njJVsRh2cj6al/mXaluKBFnG2TX Ys/SdzkSkpzhVOfce16MmxJ6HjJgJrhqv7nSiMQ9m3RmwPAgxTiK6fbyLx+d9dxhRihv J0+3E+fanrpTuGJEw4SjaLsldCFj1uk+w/8vFhFx/QyUuOBCbOC7g/fX16tbdsKEYa5a waIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784542754; x=1785147554; h=content-transfer-encoding:content-type:in-reply-to:organization :content-language:references:cc:to:subject:from: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=O+rneuRae7ccfS7HwBJRtw/KkE2FTct/JS+yPwRVhak=; b=bTjdU+Rxe/+3TAgAsc0PWFPj84qk1OOXnRxGSA7b7d/MFurMsHFMuDyLoayFzrMdUs JjfKhtS6Leumoa93F0Ktbh+oOpHiCCCUAom+nPQ6T5HkqRC6mtviCzkOv1BD5iKhqyod PEepptPG76o9fFhRMEu6O7TYb/BWAxYuxUkor+QgCdACYrpZVyPK9hUd6LTpa4B56CqN xXVH/Lx+MDVUBaxCQ3tHzwsYtnegoXeatDi2hAh8jUVZaFlfJgadxcSkggrW89J+C0WG Z+kfMcyXt6AEKdYOqfeab8AMFaqpKRIbvywamYWoPG++uDRjkhu6fbUYULGhIS7jEdok K4Kg== X-Forwarded-Encrypted: i=1; AHgh+RqAy+NS3ZR2J8dM3aPzYR1tjFn/71lDQk3BuBs+04Ap8rHQk8TtAqHOszwGds8bf89EqC5hq6i7l78dwTE=@vger.kernel.org X-Gm-Message-State: AOJu0Yx0qIOImy+Wn46RNlh4IM+nnTrzUiQKL7ao1l24E50LinUiPzM6 si3c1WWvudqwM3Sy8EJuMLXhmP5qtjpJxlO4p8xyjNR5/lfsiJkLf0ExVLkcV8x08VX3cuRA9nt H3O0ByQvmkFDKsglq2nfaYj9yMa6uJGNoEcRMEjrip/x7dJItd30ltLSPVEhI687R3qQ= X-Gm-Gg: AfdE7cnke/x2Umgvg3VfjKM9iwL5e1ydFYdpM850FagU2/hhvVVJcY9dxYdbli9XvPN A8R6ajWL90z3MAcDwkkV6+5ySjPleiyNh2RCf0QapBdDi1+eU+1ppQPSjFla0FjUqCCXt679Kjk 0ivQXM19/xnP6pfuQIKz3REIkEDuau4xUe6JuZGYNp/oWjS0FZ3iOvFzJY5IKvPf5jvFjY46v+3 dqH/LbhP0qcfsCiRjBLWdwVsI1nwACpWDcEcdL+s2Vqn5v2OaMXmJGrTFC6dYe89YqQbsqfwbz2 MCgQZGqa9RHk2CGtWcAD7KpPszMVCzwzqVM1Uy8egsFBJYRXFjAgf9OeUUwjMXP/waCfY3R5NrW jfBPyxBk2KWc+35EkJt/Py4U0jxU= X-Received: by 2002:a05:6a00:9093:b0:848:70b4:ebbe with SMTP id d2e1a72fcca58-84c294d4beamr14636013b3a.41.1784542753618; Mon, 20 Jul 2026 03:19:13 -0700 (PDT) X-Received: by 2002:a05:6a00:9093:b0:848:70b4:ebbe with SMTP id d2e1a72fcca58-84c294d4beamr14635983b3a.41.1784542753160; Mon, 20 Jul 2026 03:19:13 -0700 (PDT) Received: from [10.92.203.75] ([202.46.23.19]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84c2adfdfe9sm5346784b3a.27.2026.07.20.03.19.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jul 2026 03:19:12 -0700 (PDT) Message-ID: Date: Mon, 20 Jul 2026 15:48:51 +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 From: Harshal Dev Subject: Re: [PATCH 1/6] tee: qcomtee: Track the object invocation context To: Sumit Garg Cc: Amirreza Zarrabi , Basant Kumar , Apurupa Pattapu , Arun Kumar Neelakantam , op-tee@lists.trustedfirmware.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Konrad Dybcio , Bjorn Andersson , jenswi@kernel.org References: <20260707-qcom_uefisecapp_migrate_qcomtee-v1-0-f659cbd5d04c@oss.qualcomm.com> <20260707-qcom_uefisecapp_migrate_qcomtee-v1-1-f659cbd5d04c@oss.qualcomm.com> <534f6507-dd46-432b-80cd-87c17e3e0a71@oss.qualcomm.com> Content-Language: en-US Organization: Qualcomm In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-ORIG-GUID: b89zHbccBKZM9ROoAKrSeK3gW0kudKsy X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzIwMDExNSBTYWx0ZWRfX8Dczd1kBA7q5 TqM0ZhrQYm8C7hGVoSZ+sZTkVc/frdE5CnTahp49ZquDdsVVrtlqoxOfobzXqzz4+LBKIf5NWeg miFGELNhYuJq1Wdk7I3NRnH9Y/ISsOJW8/zdmPSXlHRQfJzFqrX8eBadMAbTAAXunAt3NOWzjaN E0PL326xwTi7H5aXJ4rOjaGNykQQZ8p1d+x8D//xApr01vKBxPmYCCHyTSF6k164VfIMGUFz7eF GDNeUoPpvcCb6C5FcAkiqJVYDWtIQrvB1fe1DsXtFurUkeUyOCW5BxTcRRm/MpK0yCzF0YBYxoT zvDqzXqotcILW9OlQ1xK47Z2+rN6cfHUotYNE+bdwkq//cnWEOc8ToE4shh45A7u52zAYFxX68f QtE4ER3TexLDJhCYMveYeRkOK9TqPuQ0m+Q+iWcGf/12THbdvVbZrq13MtqRBvrrjYdMJ1+VKsH cQVuKl8zN95wfvp1iIw== X-Authority-Analysis: v=2.4 cv=RPmD2Yi+ c=1 sm=1 tr=0 ts=6a5df622 cx=c_pps a=mDZGXZTwRPZaeRUbqKGCBw==:117 a=j4ogTh8yFefVWWEFDRgCtg==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yx91gb_oNiZeI1HMLzn7:22 a=NEAV23lmAAAA:8 a=P-IC7800AAAA:8 a=EUspDBNiAAAA:8 a=VZT3vSEkKENZW7lRfPUA:9 a=QEXdDO2ut3YA:10 a=zc0IvFSfCIW2DFIPzwfm:22 a=d3PnA9EDa4IxuAV0gXij:22 X-Proofpoint-GUID: b89zHbccBKZM9ROoAKrSeK3gW0kudKsy X-Proofpoint-Spam-Info: AW1haW4tMjYwNzIwMDExNSBTYWx0ZWRfX2AKDQa9331k6 PfRYGEWzbxvV2K0TpOlDD6ks+3cTZZF5d61a1F9exg6WgdrGBtJEqF+9FksCiRXmvISwO9OnUAy yoLqk9gOyqI9Bpai45cGyrjaqBAvbOA= 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-20_02,2026-07-17_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 impostorscore=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 spamscore=0 bulkscore=0 malwarescore=0 adultscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607200115 Hi Sumit, On 17-07-2026 01:56 pm, Sumit Garg wrote: > On Thu, Jul 16, 2026 at 12:28:25PM +0530, Harshal Dev wrote: >> Hi Amir, >> >> On 7/15/2026 5:17 AM, Amirreza Zarrabi wrote: >>> Hi Harshal, >>> >>> On 7/10/2026 4:37 PM, Harshal Dev wrote: >>>> Hi Amir, >>>> >>>> On 7/8/2026 11:31 AM, Amirreza Zarrabi wrote: >>>>> Hi Harshal, >>>>> >>>>> On 7/7/2026 4:11 PM, Harshal Dev wrote: >>>>>> QCOMTEE needs to distinguish between object invocations arriving from >>>>>> kernel clients and user-space clients in order to correctly marshal >>>>>> UBUF parameters and decide whether certain operations should be permitted. >>>>>> >>>>>> Add a kernel_ctx flag to struct qcomtee_object_invoke_context to track >>>>>> the context of object invocation. Objects invoked from the kernel-space >>>>>> are expected to have the MSB of their 64-bit object-id set to indicate a >>>>>> kernel context, whereas objects invoked from user-space should not set it. >>>>>> To ensure this, we restrict the object-id space of user-space invoked >>>>>> objects to 32-bits. This is in-line with QTEE expectation of 32-bit object >>>>>> ids. >>>>>> >>>>>> Signed-off-by: Amirreza Zarrabi >>>>>> Signed-off-by: Harshal Dev >>>>>> --- >>>>>> drivers/tee/qcomtee/call.c | 24 ++++++++++++++++++++++-- >>>>>> drivers/tee/qcomtee/qcomtee.h | 6 ++++++ >>>>>> drivers/tee/qcomtee/qcomtee_object.h | 8 ++++++-- >>>>>> drivers/tee/tee_core.c | 4 ++++ >>>>>> 4 files changed, 38 insertions(+), 4 deletions(-) >>>>>> >>>>>> diff --git a/drivers/tee/qcomtee/call.c b/drivers/tee/qcomtee/call.c >>>>>> index 0efc5646242a..a74a54d67b06 100644 >>>>>> --- a/drivers/tee/qcomtee/call.c >>>>>> +++ b/drivers/tee/qcomtee/call.c >>>>>> @@ -397,11 +397,31 @@ static int qcomtee_object_invoke(struct tee_context *ctx, >>>>>> { >>>>>> struct qcomtee_context_data *ctxdata = ctx->data; >>>>>> struct qcomtee_object *object; >>>>>> + bool kernel_ctx = false; >>>>>> int i, ret, result; >>>>>> >>>>>> if (qcomtee_params_check(params, arg->num_params)) >>>>>> return -EINVAL; >>>>>> >>>>>> + /* Obtain the invocation context information from the MSB of the object >>>>>> + * `id` field. >>>>>> + */ >>>>>> + kernel_ctx = QCOMTEE_GET_CLIENT_CTX(arg->id); >>>>>> + /* User-space identifies a NULL object via a 32-bit TEE_OBJREF_NULL id, whereas >>>>>> + * the kernel uses as 64-bit object-id. Hence, we check for a NULL object by >>>>>> + * sign-extending the object-id to 64 bits. If user-space is indeed invoking a >>>>>> + * NULL object we must extend the object-id to 64-bits from here on so that >>>>>> + * QCOMTEE can recognize it. >>>>>> + */ >>>>>> + if (!kernel_ctx && ((s64)(s32)arg->id) == TEE_OBJREF_NULL) >>>>>> + arg->id = TEE_OBJREF_NULL; >>>>> >>>>> Does it need to be MSB -- why bit 63? the object ID supported by QTEE is 32-bit anyway. >>>>> Let's mask the upper 32-bit and do something like kernel_ctx = !!upper_32_bits(id). >>>>> What do you think? >>>> >>>> I agree. Instead of checking for kernel-ctx by right shifting, I can use this approach. >>>> QTEE objects invoked from user-space (including NULL object) will always have their >>>> object-id constrained to lower 32 bits anyway as per PR: https://github.com/quic/quic-teec/pull/27 >>>> >>>> And for kernel-space invoked QTEE objects, upper 32-bits would be set for NULL object, >>>> and 63rd bit expected to be set as well. >>>> >>> >>> Re-thinking this, I'm a bit concerned about overloading id while keeping it as a u64, >>> and then filtering its upper 32 bits in tee_ioctl_object_invoke(). It feels unintuitive, >>> as it naturally raises the question: if only the lower 32 bits are meaningful, >>> why is id a `u64` in the first place? >>> >>> What if we make the caller origin explicit instead, for example: >>> >>> enum tee_object_invoke_origin { >>> TEE_OBJECT_INVOKE_USERSPACE, >>> TEE_OBJECT_INVOKE_KERNEL, >>> }; >>> >>> and then pass it through the backend op: >>> >>> int (*object_invoke_func)(struct tee_context *ctx, >>> struct tee_ioctl_object_invoke_arg *arg, >>> struct tee_param *param, >>> enum tee_object_invoke_origin origin); >>> >>> It seems more straightforward and avoids encoding caller-origin metadata into id. >>> If you are OK, let's do this. >>> >> >> Honestly, this approach makes everything a lot more easier, since we don't need complex >> bit manipulation in back-end to filter the upper 32 bits and handle the case of >> TEE_OBJREF_NULL. I can also then drop the PR: https://github.com/quic/quic-teec/pull/27 >> >> I am fine with updating this callback and calling it with TEE_OBJECT_INVOKE_USERSPACE from >> https://elixir.bootlin.com/linux/v7.1/source/drivers/tee/tee_core.c#L704 >> and TEE_OBJECT_INVOKE_KERNEL from the newly introduced tee_client_object_invoke_func(). >> >> But is there any special reason for choosing an enum over a boolean value here? Are we planning >> to extend the enum later to introduce any other context information? > > I think enum is just better to provide enough info for the flag. > Ack. >> >> I am fine with this approach. I hope the OP-TEE maintainers @Sumit are fine as well with the >> new parameter addition in the callback. > > That's fine with me if it simplifies the object handling for you folks. Ack, thank you for your review, I will spin a v2 based on this feedback. Regards, Harshal > > -Sumit