From: neil.armstrong@linaro.org
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Amirreza Zarrabi <quic_azarrabi@quicinc.com>
Cc: "Bjorn Andersson" <andersson@kernel.org>,
"Konrad Dybcio" <konrad.dybcio@linaro.org>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
srinivas.kandagatla@linaro.org, bartosz.golaszewski@linaro.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH RFC 0/3] Implement Qualcomm TEE IPC and ioctl calls
Date: Wed, 3 Jul 2024 14:48:29 +0200 [thread overview]
Message-ID: <06f8113c-8e83-411a-a4bf-bfadc2560882@linaro.org> (raw)
In-Reply-To: <umwai5fxohuz6apprv6ouhdrnomal4a7cmyhmzpf6dnamnvti2@un4hxx52hkge>
On 03/07/2024 13:36, Dmitry Baryshkov wrote:
> On Tue, Jul 02, 2024 at 10:57:35PM GMT, Amirreza Zarrabi wrote:
<snip>
>
>>
>> Can we use TEE subsystem?
>> -------------------------
>> There are workarounds for some of the issues above. The question is if we
>> should define our own UAPI or try to use a hack-y way of fitting into
>> the TEE subsystem. I am using word hack-y, as most of the workaround
>> involves:
>>
>> - "diverging from the definition". For instance, ignoring the session
>> open and close ioctl calls or use file descriptors for all remote
>> resources (as, fd is the closet to capability) which undermines the
>> isolation provided by the contexts,
>>
>> - "overloading the variables". For instance, passing object ID as file
>> descriptors in a place of session ID, or
>>
>> - "bypass TEE subsystem". For instance, extensively rely on meta
>> parameters or push everything (e.g. kernel services) to the back-end
>> driver, which means leaving almost all TEE subsystem unused.
Why can't you extend the TEE subsystem with those features ?
>>
>> We cannot take the full benefits of TEE subsystem and may need to
>> implement most of the requirements in the back-end driver. Also, as
>> discussed above, the UAPI is not suitable for capability-based use cases.
>> We proposed a new set of ioctl calls for SMC-Invoke driver.
>>
>> In this series we posted three patches. We implemented a transport
>> driver that provides qcom_tee_object. Any object on secure side is
>> represented with an instance of qcom_tee_object and any struct exposed
>> to TEE should embed an instance of qcom_tee_object. Any, support for new
>> services, e.g. memory object, RPMB, userspace clients or supplicants are
>> implemented independently from the driver.
>>
>> We have a simple memory object and a user driver that uses
>> qcom_tee_object.
>
> Could you please point out any user for the uAPI? I'd like to understand
> how does it from from the userspace point of view.
<snip>
next prev parent reply other threads:[~2024-07-03 12:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-03 5:57 Amirreza Zarrabi
2024-07-03 5:57 ` [PATCH RFC 1/3] firmware: qcom: implement object invoke support Amirreza Zarrabi
2024-07-03 12:13 ` Dmitry Baryshkov
2024-07-03 21:39 ` Amirreza Zarrabi
2024-07-04 7:34 ` Dmitry Baryshkov
2024-07-25 3:19 ` Amirreza Zarrabi
2024-07-25 4:09 ` Dmitry Baryshkov
2024-07-25 4:15 ` Amirreza Zarrabi
2024-07-25 4:32 ` Dmitry Baryshkov
2024-07-18 11:27 ` Krzysztof Kozlowski
2024-07-03 5:57 ` [PATCH RFC 2/3] firmware: qcom: implement memory object support for TEE Amirreza Zarrabi
2024-07-03 5:57 ` [PATCH RFC 3/3] firmware: qcom: implement ioctl for TEE object invocation Amirreza Zarrabi
2024-07-03 11:36 ` [PATCH RFC 0/3] Implement Qualcomm TEE IPC and ioctl calls Dmitry Baryshkov
2024-07-03 12:48 ` neil.armstrong [this message]
2024-07-09 23:16 ` Amirreza Zarrabi
2024-07-17 12:31 ` Dmitry Baryshkov
2024-07-18 10:00 ` Sumit Garg
2024-07-25 3:16 ` Amirreza Zarrabi
2024-07-17 14:52 ` Jens Wiklander
2024-07-25 1:55 ` Amirreza Zarrabi
2024-07-09 10:01 ` Konrad Dybcio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=06f8113c-8e83-411a-a4bf-bfadc2560882@linaro.org \
--to=neil.armstrong@linaro.org \
--cc=andersson@kernel.org \
--cc=bartosz.golaszewski@linaro.org \
--cc=christian.koenig@amd.com \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=konrad.dybcio@linaro.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_azarrabi@quicinc.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=sumit.semwal@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®