mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>


  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®