Qualcomm TEE (QTEE) hosts Trusted Applications (TAs) and services in
the secure world, accessed via objects. A QTEE client can invoke these
objects to request services. Similarly, QTEE can request services from
the nonsecure world using objects exported to the secure world.
Add low-level primitives to facilitate the invocation of objects hosted
in QTEE, as well as those hosted in the nonsecure world.
If support for object invocation is available, the qcom_scm allocates
a dedicated child platform device. The driver for this device communicates
with QTEE using low-level primitives.
Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Harshal Dev <quic_hdev@quicinc.com>
Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
---
drivers/firmware/qcom/qcom_scm.c | 128 +++++++++++++++++++++++++++++++++
drivers/firmware/qcom/qcom_scm.h | 7 ++
include/linux/firmware/qcom/qcom_scm.h | 6 ++
3 files changed, 141 insertions(+)
diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index edeae6cdcf31..96d5cf40a74c 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2094,6 +2094,124 @@ static int qcom_scm_qseecom_init(struct qcom_scm *scm)
#endif /* CONFIG_QCOM_QSEECOM */
+/**
+ * qcom_scm_qtee_invoke_smc() - Invoke a QTEE object.
+ * @inbuf: start address of memory area used for inbound buffer.
+ * @inbuf_size: size of the memory area used for inbound buffer.
+ * @outbuf: start address of memory area used for outbound buffer.
+ * @outbuf_size: size of the memory area used for outbound buffer.
+ * @result: result of QTEE object invocation.
+ * @response_type: response type returned by QTEE.
+ *
+ * @response_type determines how the contents of @inbuf and @outbuf
+ * should be processed.
+ *
+ * Return: On success, return 0 or <0 on failure.
+ */
+int qcom_scm_qtee_invoke_smc(phys_addr_t inbuf, size_t inbuf_size,
+ phys_addr_t outbuf, size_t outbuf_size,
+ u64 *result, u64 *response_type)
+{
+ struct qcom_scm_desc desc = {
+ .svc = QCOM_SCM_SVC_SMCINVOKE,
+ .cmd = QCOM_SCM_SMCINVOKE_INVOKE,
+ .owner = ARM_SMCCC_OWNER_TRUSTED_OS,
+ .args[0] = inbuf,
+ .args[1] = inbuf_size,
+ .args[2] = outbuf,
+ .args[3] = outbuf_size,
+ .arginfo = QCOM_SCM_ARGS(4, QCOM_SCM_RW, QCOM_SCM_VAL,
+ QCOM_SCM_RW, QCOM_SCM_VAL),
+ };
+ struct qcom_scm_res res;
+ int ret;
+
+ ret = qcom_scm_call(__scm->dev, &desc, &res);
+ if (ret)
+ return ret;
+
+ *response_type = res.result[0];
+ *result = res.result[1];
+
+ return 0;
+}
+EXPORT_SYMBOL(qcom_scm_qtee_invoke_smc);
+
+/**
+ * qcom_scm_qtee_callback_response() - Submit response for callback request.
+ * @buf: start address of memory area used for outbound buffer.
+ * @buf_size: size of the memory area used for outbound buffer.
+ * @result: Result of QTEE object invocation.
+ * @response_type: Response type returned by QTEE.
+ *
+ * @response_type determines how the contents of @buf should be processed.
+ *
+ * Return: On success, return 0 or <0 on failure.
+ */
+int qcom_scm_qtee_callback_response(phys_addr_t buf, size_t buf_size,
+ u64 *result, u64 *response_type)
+{
+ struct qcom_scm_desc desc = {
+ .svc = QCOM_SCM_SVC_SMCINVOKE,
+ .cmd = QCOM_SCM_SMCINVOKE_CB_RSP,
+ .owner = ARM_SMCCC_OWNER_TRUSTED_OS,
+ .args[0] = buf,
+ .args[1] = buf_size,
+ .arginfo = QCOM_SCM_ARGS(2, QCOM_SCM_RW, QCOM_SCM_VAL),
+ };
+ struct qcom_scm_res res;
+ int ret;
+
+ ret = qcom_scm_call(__scm->dev, &desc, &res);
+ if (ret)
+ return ret;
+
+ *response_type = res.result[0];
+ *result = res.result[1];
+
+ return 0;
+}
+EXPORT_SYMBOL(qcom_scm_qtee_callback_response);
+
+static void qcom_scm_qtee_free(void *data)
+{
+ struct platform_device *qtee_dev = data;
+
+ platform_device_unregister(qtee_dev);
+}
+
+static int qcom_scm_qtee_init(struct qcom_scm *scm)
+{
+ struct platform_device *qtee_dev;
+ u64 result, response_type;
+ int ret;
+
+ /*
+ * Check if QTEE supports smcinvoke:
+ * This will fail with -EINVAL due to invalid buffers, but first,
+ * it checks whether the call is supported in QTEE syscall handler.
+ * If not supported, -EIO is returned.
+ */
+ ret = qcom_scm_qtee_invoke_smc(0, 0, 0, 0, &result, &response_type);
+ if (ret == -EIO)
+ return -EIO;
+
+ /* Setup QTEE interface device. */
+ qtee_dev = platform_device_alloc("qcomtee", -1);
+ if (!qtee_dev)
+ return -ENOMEM;
+
+ qtee_dev->dev.parent = scm->dev;
+
+ ret = platform_device_add(qtee_dev);
+ if (ret) {
+ platform_device_put(qtee_dev);
+ return ret;
+ }
+
+ return devm_add_action_or_reset(scm->dev, qcom_scm_qtee_free, qtee_dev);
+}
+
/**
* qcom_scm_is_available() - Checks if SCM is available
*/
@@ -2326,6 +2444,16 @@ static int qcom_scm_probe(struct platform_device *pdev)
ret = qcom_scm_qseecom_init(scm);
WARN(ret < 0, "failed to initialize qseecom: %d\n", ret);
+ /*
+ * Initialize the QTEE object interface.
+ *
+ * This only represents the availability for QTEE object invocation
+ * and callback support. On failure, ignore the result. Any subsystem
+ * depending on it may fail if it tries to access this interface.
+ */
+ ret = qcom_scm_qtee_init(scm);
+ WARN(ret < 0, "failed to initialize qcomtee: %d\n", ret);
+
return 0;
}
diff --git a/drivers/firmware/qcom/qcom_scm.h b/drivers/firmware/qcom/qcom_scm.h
index 0e8dd838099e..a56c8212cc0c 100644
--- a/drivers/firmware/qcom/qcom_scm.h
+++ b/drivers/firmware/qcom/qcom_scm.h
@@ -156,6 +156,13 @@ int qcom_scm_shm_bridge_enable(struct device *scm_dev);
#define QCOM_SCM_SVC_GPU 0x28
#define QCOM_SCM_SVC_GPU_INIT_REGS 0x01
+/* ARM_SMCCC_OWNER_TRUSTED_OS calls */
+
+#define QCOM_SCM_SVC_SMCINVOKE 0x06
+#define QCOM_SCM_SMCINVOKE_INVOKE_LEGACY 0x00
+#define QCOM_SCM_SMCINVOKE_CB_RSP 0x01
+#define QCOM_SCM_SMCINVOKE_INVOKE 0x02
+
/* common error codes */
#define QCOM_SCM_V2_EBUSY -12
#define QCOM_SCM_ENOMEM -5
diff --git a/include/linux/firmware/qcom/qcom_scm.h b/include/linux/firmware/qcom/qcom_scm.h
index 0f667bf1d4d9..a55ca771286b 100644
--- a/include/linux/firmware/qcom/qcom_scm.h
+++ b/include/linux/firmware/qcom/qcom_scm.h
@@ -175,4 +175,10 @@ static inline int qcom_scm_qseecom_app_send(u32 app_id,
#endif /* CONFIG_QCOM_QSEECOM */
+int qcom_scm_qtee_invoke_smc(phys_addr_t inbuf, size_t inbuf_size,
+ phys_addr_t outbuf, size_t outbuf_size,
+ u64 *result, u64 *response_type);
+int qcom_scm_qtee_callback_response(phys_addr_t buf, size_t buf_size,
+ u64 *result, u64 *response_type);
+
#endif
--
2.34.1On 8/13/25 2:35 AM, Amirreza Zarrabi wrote:
> Qualcomm TEE (QTEE) hosts Trusted Applications (TAs) and services in
> the secure world, accessed via objects. A QTEE client can invoke these
> objects to request services. Similarly, QTEE can request services from
> the nonsecure world using objects exported to the secure world.
>
> Add low-level primitives to facilitate the invocation of objects hosted
> in QTEE, as well as those hosted in the nonsecure world.
>
> If support for object invocation is available, the qcom_scm allocates
> a dedicated child platform device. The driver for this device communicates
> with QTEE using low-level primitives.
>
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> Tested-by: Harshal Dev <quic_hdev@quicinc.com>
> Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
> ---
[...]
> +int qcom_scm_qtee_invoke_smc(phys_addr_t inbuf, size_t inbuf_size,
> + phys_addr_t outbuf, size_t outbuf_size,
> + u64 *result, u64 *response_type)
> +{
> + struct qcom_scm_desc desc = {
> + .svc = QCOM_SCM_SVC_SMCINVOKE,
> + .cmd = QCOM_SCM_SMCINVOKE_INVOKE,
> + .owner = ARM_SMCCC_OWNER_TRUSTED_OS,
> + .args[0] = inbuf,
> + .args[1] = inbuf_size,
> + .args[2] = outbuf,
> + .args[3] = outbuf_size,
> + .arginfo = QCOM_SCM_ARGS(4, QCOM_SCM_RW, QCOM_SCM_VAL,
> + QCOM_SCM_RW, QCOM_SCM_VAL),
> + };
> + struct qcom_scm_res res;
> + int ret;
> +
> + ret = qcom_scm_call(__scm->dev, &desc, &res);
> + if (ret)
> + return ret;
> +
> + *response_type = res.result[0];
> + *result = res.result[1];
These are dereferenced without checking, which will surely upset static
checkers (and users)
I see that res.result[2] should also return some (aptly named) "data"
which you handled in v1, but dropped in v2 (without a comment AFAICT)
Looking at it, we could probably wrap it in qcom_scm_qseecom_call()
which this seems to be fit for
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(qcom_scm_qtee_invoke_smc);
> +
> +/**
> + * qcom_scm_qtee_callback_response() - Submit response for callback request.
> + * @buf: start address of memory area used for outbound buffer.
> + * @buf_size: size of the memory area used for outbound buffer.
> + * @result: Result of QTEE object invocation.
> + * @response_type: Response type returned by QTEE.
> + *
> + * @response_type determines how the contents of @buf should be processed.
> + *
> + * Return: On success, return 0 or <0 on failure.
> + */
> +int qcom_scm_qtee_callback_response(phys_addr_t buf, size_t buf_size,
> + u64 *result, u64 *response_type)
These should be aligned
> +{
> + struct qcom_scm_desc desc = {
> + .svc = QCOM_SCM_SVC_SMCINVOKE,
> + .cmd = QCOM_SCM_SMCINVOKE_CB_RSP,
> + .owner = ARM_SMCCC_OWNER_TRUSTED_OS,
> + .args[0] = buf,
> + .args[1] = buf_size,
> + .arginfo = QCOM_SCM_ARGS(2, QCOM_SCM_RW, QCOM_SCM_VAL),
> + };
> + struct qcom_scm_res res;
> + int ret;
> +
> + ret = qcom_scm_call(__scm->dev, &desc, &res);
> + if (ret)
> + return ret;
> +
> + *response_type = res.result[0];
> + *result = res.result[1];
this also seems like a good candidate for qcom_scm_qseecom_call()
[...]
> /**
> * qcom_scm_is_available() - Checks if SCM is available
> */
> @@ -2326,6 +2444,16 @@ static int qcom_scm_probe(struct platform_device *pdev)
> ret = qcom_scm_qseecom_init(scm);
> WARN(ret < 0, "failed to initialize qseecom: %d\n", ret);
>
> + /*
> + * Initialize the QTEE object interface.
> + *
> + * This only represents the availability for QTEE object invocation
> + * and callback support. On failure, ignore the result. Any subsystem
> + * depending on it may fail if it tries to access this interface.
> + */
> + ret = qcom_scm_qtee_init(scm);
> + WARN(ret < 0, "failed to initialize qcomtee: %d\n", ret);
This will throw a WARN on *a lot* of platforms, ranging from
Chromebooks running TF-A (with a reduced SMC handler), through
platforms requiring QCOM_SCM_SMCINVOKE_INVOKE_LEGACY (0x00) cmd
Konrad
On 8/13/2025 7:53 PM, Konrad Dybcio wrote:
> On 8/13/25 2:35 AM, Amirreza Zarrabi wrote:
>> Qualcomm TEE (QTEE) hosts Trusted Applications (TAs) and services in
>> the secure world, accessed via objects. A QTEE client can invoke these
>> objects to request services. Similarly, QTEE can request services from
>> the nonsecure world using objects exported to the secure world.
>>
>> Add low-level primitives to facilitate the invocation of objects hosted
>> in QTEE, as well as those hosted in the nonsecure world.
>>
>> If support for object invocation is available, the qcom_scm allocates
>> a dedicated child platform device. The driver for this device communicates
>> with QTEE using low-level primitives.
>>
>> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
>> Tested-by: Harshal Dev <quic_hdev@quicinc.com>
>> Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
>> ---
>
> [...]
>
>> +int qcom_scm_qtee_invoke_smc(phys_addr_t inbuf, size_t inbuf_size,
>> + phys_addr_t outbuf, size_t outbuf_size,
>> + u64 *result, u64 *response_type)
>> +{
>> + struct qcom_scm_desc desc = {
>> + .svc = QCOM_SCM_SVC_SMCINVOKE,
>> + .cmd = QCOM_SCM_SMCINVOKE_INVOKE,
>> + .owner = ARM_SMCCC_OWNER_TRUSTED_OS,
>> + .args[0] = inbuf,
>> + .args[1] = inbuf_size,
>> + .args[2] = outbuf,
>> + .args[3] = outbuf_size,
>> + .arginfo = QCOM_SCM_ARGS(4, QCOM_SCM_RW, QCOM_SCM_VAL,
>> + QCOM_SCM_RW, QCOM_SCM_VAL),
>> + };
>> + struct qcom_scm_res res;
>> + int ret;
>> +
>> + ret = qcom_scm_call(__scm->dev, &desc, &res);
>> + if (ret)
>> + return ret;
>> +
>> + *response_type = res.result[0];
>> + *result = res.result[1];
>
> These are dereferenced without checking, which will surely upset static
> checkers (and users)
>
There is no consistency in qcom_scm.c; I see multiple instances where
similar dereferencing is already happening in this file. However, I'll
add the if (...) check to be sure. The reason I initially skipped it
is that this API has a single user -- the TEE subsystem.
> I see that res.result[2] should also return some (aptly named) "data"
> which you handled in v1, but dropped in v2 (without a comment AFAICT)
>
> Looking at it, we could probably wrap it in qcom_scm_qseecom_call()
> which this seems to be fit for
>
I cannot use qcom_scm_qseecom_call() because this is not a qseecom
transport. It's a new transport called smcinvoke, which, for instance,
does not require a lock.
The data field is intended for qseecom over smcinvoke, which we will
never support -- so there's no reason to return it.
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(qcom_scm_qtee_invoke_smc);
>> +
>> +/**
>> + * qcom_scm_qtee_callback_response() - Submit response for callback request.
>> + * @buf: start address of memory area used for outbound buffer.
>> + * @buf_size: size of the memory area used for outbound buffer.
>> + * @result: Result of QTEE object invocation.
>> + * @response_type: Response type returned by QTEE.
>> + *
>> + * @response_type determines how the contents of @buf should be processed.
>> + *
>> + * Return: On success, return 0 or <0 on failure.
>> + */
>> +int qcom_scm_qtee_callback_response(phys_addr_t buf, size_t buf_size,
>> + u64 *result, u64 *response_type)
>
> These should be aligned
Ack.
>
>> +{
>> + struct qcom_scm_desc desc = {
>> + .svc = QCOM_SCM_SVC_SMCINVOKE,
>> + .cmd = QCOM_SCM_SMCINVOKE_CB_RSP,
>> + .owner = ARM_SMCCC_OWNER_TRUSTED_OS,
>> + .args[0] = buf,
>> + .args[1] = buf_size,
>> + .arginfo = QCOM_SCM_ARGS(2, QCOM_SCM_RW, QCOM_SCM_VAL),
>> + };
>> + struct qcom_scm_res res;
>> + int ret;
>> +
>> + ret = qcom_scm_call(__scm->dev, &desc, &res);
>> + if (ret)
>> + return ret;
>> +
>> + *response_type = res.result[0];
>> + *result = res.result[1];
>
> this also seems like a good candidate for qcom_scm_qseecom_call()
>
ditto.
> [...]
>
>> /**
>> * qcom_scm_is_available() - Checks if SCM is available
>> */
>> @@ -2326,6 +2444,16 @@ static int qcom_scm_probe(struct platform_device *pdev)
>> ret = qcom_scm_qseecom_init(scm);
>> WARN(ret < 0, "failed to initialize qseecom: %d\n", ret);
>>
>> + /*
>> + * Initialize the QTEE object interface.
>> + *
>> + * This only represents the availability for QTEE object invocation
>> + * and callback support. On failure, ignore the result. Any subsystem
>> + * depending on it may fail if it tries to access this interface.
>> + */
>> + ret = qcom_scm_qtee_init(scm);
>> + WARN(ret < 0, "failed to initialize qcomtee: %d\n", ret);
>
> This will throw a WARN on *a lot* of platforms, ranging from
> Chromebooks running TF-A (with a reduced SMC handler), through
> platforms requiring QCOM_SCM_SMCINVOKE_INVOKE_LEGACY (0x00) cmd
>
Are you suggesting I remove the WARN? If so, how should the user be notified?
Should the error simply be ignored?
> Konrad
Thanks,
Amir
On 8/13/25 11:37 PM, Amirreza Zarrabi wrote: > > > On 8/13/2025 7:53 PM, Konrad Dybcio wrote: >> On 8/13/25 2:35 AM, Amirreza Zarrabi wrote: >>> Qualcomm TEE (QTEE) hosts Trusted Applications (TAs) and services in >>> the secure world, accessed via objects. A QTEE client can invoke these >>> objects to request services. Similarly, QTEE can request services from >>> the nonsecure world using objects exported to the secure world. >>> >>> Add low-level primitives to facilitate the invocation of objects hosted >>> in QTEE, as well as those hosted in the nonsecure world. >>> >>> If support for object invocation is available, the qcom_scm allocates >>> a dedicated child platform device. The driver for this device communicates >>> with QTEE using low-level primitives. >>> >>> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> >>> Tested-by: Harshal Dev <quic_hdev@quicinc.com> >>> Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com> >>> --- [...] >>> /** >>> * qcom_scm_is_available() - Checks if SCM is available >>> */ >>> @@ -2326,6 +2444,16 @@ static int qcom_scm_probe(struct platform_device *pdev) >>> ret = qcom_scm_qseecom_init(scm); >>> WARN(ret < 0, "failed to initialize qseecom: %d\n", ret); >>> >>> + /* >>> + * Initialize the QTEE object interface. >>> + * >>> + * This only represents the availability for QTEE object invocation >>> + * and callback support. On failure, ignore the result. Any subsystem >>> + * depending on it may fail if it tries to access this interface. >>> + */ >>> + ret = qcom_scm_qtee_init(scm); >>> + WARN(ret < 0, "failed to initialize qcomtee: %d\n", ret); >> >> This will throw a WARN on *a lot* of platforms, ranging from >> Chromebooks running TF-A (with a reduced SMC handler), through >> platforms requiring QCOM_SCM_SMCINVOKE_INVOKE_LEGACY (0x00) cmd >> > > Are you suggesting I remove the WARN? If so, how should the user be notified? > Should the error simply be ignored? I suggest using dev_info/dev_notice, WARN prints multiple dozen lines and taints the kernel Konrad
On 8/14/2025 8:52 AM, Konrad Dybcio wrote: > On 8/13/25 11:37 PM, Amirreza Zarrabi wrote: >> >> >> On 8/13/2025 7:53 PM, Konrad Dybcio wrote: >>> On 8/13/25 2:35 AM, Amirreza Zarrabi wrote: >>>> Qualcomm TEE (QTEE) hosts Trusted Applications (TAs) and services in >>>> the secure world, accessed via objects. A QTEE client can invoke these >>>> objects to request services. Similarly, QTEE can request services from >>>> the nonsecure world using objects exported to the secure world. >>>> >>>> Add low-level primitives to facilitate the invocation of objects hosted >>>> in QTEE, as well as those hosted in the nonsecure world. >>>> >>>> If support for object invocation is available, the qcom_scm allocates >>>> a dedicated child platform device. The driver for this device communicates >>>> with QTEE using low-level primitives. >>>> >>>> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> >>>> Tested-by: Harshal Dev <quic_hdev@quicinc.com> >>>> Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com> >>>> --- > > [...] > >>>> /** >>>> * qcom_scm_is_available() - Checks if SCM is available >>>> */ >>>> @@ -2326,6 +2444,16 @@ static int qcom_scm_probe(struct platform_device *pdev) >>>> ret = qcom_scm_qseecom_init(scm); >>>> WARN(ret < 0, "failed to initialize qseecom: %d\n", ret); >>>> >>>> + /* >>>> + * Initialize the QTEE object interface. >>>> + * >>>> + * This only represents the availability for QTEE object invocation >>>> + * and callback support. On failure, ignore the result. Any subsystem >>>> + * depending on it may fail if it tries to access this interface. >>>> + */ >>>> + ret = qcom_scm_qtee_init(scm); >>>> + WARN(ret < 0, "failed to initialize qcomtee: %d\n", ret); >>> >>> This will throw a WARN on *a lot* of platforms, ranging from >>> Chromebooks running TF-A (with a reduced SMC handler), through >>> platforms requiring QCOM_SCM_SMCINVOKE_INVOKE_LEGACY (0x00) cmd >>> >> >> Are you suggesting I remove the WARN? If so, how should the user be notified? >> Should the error simply be ignored? > > I suggest using dev_info/dev_notice, WARN prints multiple dozen lines > and taints the kernel > > Konrad Ack. Amir
© 2016 - 2025 Red Hat, Inc.