[RFC] core: implement OCALLs #3673

HernanGatta · 2020-03-18T04:57:40Z

Overview

This PR implements Out Calls, or OCALLs for short. It allows a TA to invoke functions on its CA, effectively TEEC_InvokeCommand in reverse.

This is a re-implementation of #3292, but all processing is done in-thread. That is, the normal world thread that invokes a command on a TA, which results in an OCALL, is the one that handles the OCALL, as opposed to using an out-of-thread call queue.

Related PRs: Linux, OP-TEE Client, OP-TEE Examples.

Note: PRs into ~~the driver~~, ~~the client library~~, ~~the examples, and~~ the test suite coming shortly. ~~I'll update the GitHub issue we were discussing this on before once the PR's are up (assuming I can re-open it.)~~

The life of an OCALL

When opening a session, the CA uses a new API: TEEC_OpenSessionEx. This function optionally takes a list of typed settings. One such setting is the OCALL setting, which allows the developer to set the OCALL handler function, and an arbitrary context pointer. The function goes on to ascertain that OP-TEE reports OCALL support. If so, the function uses TEEC_OpenSession under the covers to open a session. Lastly, it sets the OCALL setting in the session object.

From this point forward, by virtue of having configured OCALLs, the CA's calls into TEEC_InvokeCommand are passed via a new IOCTL in the TEE driver called Enclave Call, or ECALL for short. The handler for this IOCTL in the OP-TEE driver initiates a regular function invocation into OP-TEE. If the TA returns in the usual way, that is, it does not request an OCALL, the IOCTL behaves just the same as the Invoke one.

On the other hand, the TA can call TEE_InvokeCACommand, whose signature is similar to TEEC_InvokeTACommand. This function, implemented in libutee, calls into the OCALL PTA.

The OCALL PTA examines the OCALL parameters, and determines if any of them are memory references. If so, it computes their aggregate size and sends an RPC to normal world to request that the CA allocate shared memory of the given size. The driver stack picks up on the request, creates an OCALL context to hold the current call and RPC context, gives it an ID, and the ECALL IOCTL completes.

As part of the IOCTL completion, its values and parameters are now completely changed. A func element indicates the function that the TEE Client API must execute, in this case "Allocate shared memory", while the parameters carry the size of the requested buffer. Additionally, the ID of the OCALL context is included for resumption later.

The TEE Client API allocates shared memory the same way the TEE Supplicant does (i.e., if registered memory is available, it is not actually registered with OP-TEE). Once this is done, the result of the operation is wrapped in the IOCTL parameters and a new ECALL IOCTL is issued.

The ECALL IOCTL's logic picks up on the OCALL ID and looks up the OCALL context. The func value remains unchanged, so the IOCTL knows this is a reply to the shared memory allocation. After some simple parameter processing, the result is returned to OP-TEE via an RPC resume.

At this stage, the OCALL PTA resumes execution. Its next step is to set up RPC parameters for the OCALL RPC request. The maximum number of RPC parameters is increased to six. As such, the first RPC parameter includes the Command ID for the CA to execute, the second includes the UUID of the TA whence the OCALL request originated, and the remaining four RPC parameters are filled with those of the OCALL, after processing. Processing involves copying values, and copying memory references from TA-mapped memory into the shared memory allocated previously, if necessary. A new RPC is issued.

The RPC is picked up by normal word. The OCALL context is retrieved again, call context is saved, and the ECALL IOCTL's values are updated. The func parameter now indicates that the TEE Client API must pass the OCALL request to the CA proper, and the cmd_id value stores the Command ID that the CA knows how to interpret (i.e., the OCALL Id). The parameters are those of the OCALL as it originated in the TA, again after proper processing. The ECALL IOCTL completes.

The TEE Client API invokes the OCALL handler set previously via session settings and the CA finally gains control. The handler gets its arbitrary context pointer, the UUID of the requesting TA, and the OCALL parameters. It can modify INOUT and OUTPUT parameters freely. Once the OCALL handler returns, the TEE Client API processes parameters as needed and issues a new ECALL IOCTL, including the return value of the OCALL and its origin code.

The ECALL IOCTL recognizes this invocation as a resumption by its OCALL ID parameter, and knows that it's a response to an OCALL request by examining the func parameter. It performs the appropriate parameter processing and returns to OP-TEE with an RPC resume. The first parameter of the RPC is modified to pass the OCALL return value and origin code.

The OCALL PTA gains control once more. It processes the returned parameters, copying values and buffers as necessary into TA-mapped memory. If shared memory was allocated previously, another round of ECALL IOCTL completion followed by a reply is executed to have the CA free the memory.

All is now done and control is returned to the TA, including the return value and origin code of the OCALL.

Signed-off-by: Hernan Gatta [email protected]

lib/libutee/include/tee_api_defines.h

etienne-lms · 2020-03-19T20:14:27Z

lib/libutee/include/pta_ocall.h

+		{ 0x05ece642, 0x903f, 0x47bf, \
+			{ 0x94, 0xeb, 0x07, 0xd6, 0x14, 0x61, 0x73, 0xa1 } }
+
+#define PTA_OCALL_SEND      0


/* * Invoke a RPC Output Call to CA * * memref[0..3] can be any parameter type and are provide CA OCall handler */

Good point.

etienne-lms · 2020-03-19T20:30:23Z

mk/config.mk

@@ -547,3 +547,6 @@ CFG_SHOW_CONF_ON_BOOT ?= n
 # to a TA, so a TPM Service could use it to extend any measurement
 # taken before the service was up and running.
 CFG_CORE_TPM_EVENT_LOG ?= n
+
+# Enables support for OCALLs
+CFG_OCALL ?= y


CFG_CA_OCALL?

I don't think _CA_ would add anything useful. The name of the feature is OCALL.
The comment describing the config could mention that this is an RPC into the Client Application.

Added more info.

etienne-lms · 2020-03-19T20:38:01Z

core/include/optee_rpc_cmd.h

@@ -148,6 +150,20 @@
 */
 #define OPTEE_RPC_CMD_BENCH_REG		20

+/*
+ * Send a command to the Client Application.


"Send an OCall command to the Client Application."

etienne-lms · 2020-03-20T08:32:36Z

core/pta/ocall.c

+	return TEE_SUCCESS;
+}
+
+#define MEMREF_CHECK_AND_SET_RPC(x) 					       \


would prefer a function

Indeed, will simplify; this is ugly.

HernanGatta · 2020-03-22T08:18:03Z

A note on the style fixes commit: I assumed, apparently incorrectly, that commits would be squashed before merging, but that's not the strategy you've all been using. That's my mistake in working the way I've been working on other projects. So, I'll re-write the commit history into something that can be linearly appended to master, and the same for the other related PRs.

As-is, fixing checkpatch errors on each commit is going to be a lot of trouble. I've tried rebasing interactively atop master, and fixing errors on each commit, but that just causes merge conflicts as the rebase progresses, and I'd be fixing errors on code that was ultimately deleted or re-written anyway, so it seems like a waste of time.

Let me know if I got this wrong.

jforissier · 2020-03-23T08:39:35Z

@HernanGatta you're right, in the end we expect a set of properly formatted patches, each one addressing a specific need or adding a specific feature.

Coding style fixes can indeed be pain to do during rebase... my suggestion would be to first re-organize your current set of patches using git rebase -i. You would squash the things that make sense together and write proper descriptions, but you would not address any coding style issue yet. Then you would rebase again and use the "edit" option to re-format where needed. By doing so you will at least avoid issues with code that is added then removed.

jenswi-linaro · 2020-03-23T12:17:15Z

core/pta/ocall.c

+		case TEE_PARAM_TYPE_NONE:
+			rpc_params[n].attr = THREAD_PARAM_ATTR_NONE;
+			break;
+		case TEE_PARAM_TYPE_VALUE_INPUT:


The value types could be written more compactly as (assuming that rpc_params is zero initialized):

case TEE_PARAM_TYPE_VALUE_INPUT: case TEE_PARAM_TYPE_VALUE_INOUT: rpc_params[n].u.value.a = ca_param->value.a; rpc_params[n].u.value.b = ca_param->value.b; /*FALLTHROUGH*/ case TEE_PARAM_TYPE_VALUE_OUTPUT: rpc_params[n].attr = THREAD_PARAM_ATTR_VALUE_IN + ca_pt - TEE_PARAM_TYPE_VALUE_INPUT; break;

Ah, I like it; I wanted to get rid of the duplication but couldn't really due to the macro. I had seen code like what you suggested elsewhere in OP-TEE, but I figured that since the macro to set thread parameters was there, one is meant to use them.

Thank you for the suggestion.

Added as suggested.

jenswi-linaro · 2020-03-23T12:19:24Z

core/pta/ocall.c

+							   ca_param->value.b,
+							   0);
+			break;
+		case TEE_PARAM_TYPE_MEMREF_INPUT:


The memref code here could also be rewritten similarly to what's suggested for value params above.

Added as suggested.

jenswi-linaro · 2020-03-23T13:03:45Z

core/pta/ocall.c

+	ca_cmd_id = params[0].value.a;
+
+	/* Process OCALL parameters, if any */
+	if (pt2 == TEE_PARAM_TYPE_MEMREF_INOUT) {


How about skipping this optimization and instead always require the TA to always supply this?

Section 4.9.4 of the TEE Internal Core API v1.2.1 spec. states about calling TEE_InvokeTACommand:

Unless all parameter types are set to TEE_PARAM_TYPE_NONE, params SHALL NOT be NULL [...]

I'd like TEE_InvokeCACommand to behave as closely to TEE_InvokeTACommand as possible. So, params can be NULL if all parameter types are NONE. When this is the case, to remove the check you highlighted, TEE_InvokeCACommand would have to pass a dummy array to the PTA.

I'd argue it's best to have this check, than the alternative. Thoughts?

Edit: Perhaps dealing with the issue of an AArch32 TA running on an AArch64 kernel may cancel out this problem.

TEE_InvokeCACommand() passing a dummy array sounds good.

jenswi-linaro · 2020-03-23T13:04:39Z

core/pta/ocall.c

+	/* Process OCALL parameters, if any */
+	if (pt2 == TEE_PARAM_TYPE_MEMREF_INOUT) {
+		ca_param_types = params[0].value.b;
+		ca_params = (TEE_Param *)params[1].memref.buffer;


A TA may execute in AArch32 while we're at AArch64 here so TEE_Param will have a different layout.

I noticed that the way you've worked around this problem elsewhere is by turning TEE_Param into utee_param, then back again, for transport across the UM/KM boundary. I've taken the same approach.

Do you think it's fine that way?

Sounds good.

jenswi-linaro · 2020-03-23T13:06:08Z

core/pta/ocall.c

+			return TEE_ERROR_BAD_PARAMETERS;
+
+		/* Compute memory the CA must allocate for the OCALL params */
+		res = compute_required_mobj_size(ca_param_types, ca_params,


This prevents zero copy.
How about letting the TA allocate the buffers first and pass the pointers to those in the ca_params above?
That would simplify this function a bit too.

If so TA would need to allocate non-secure memory. There isn't yet any API for that. Consider a specific command of this OCALL PTA?

I suppose it would be an extension which would go together with the OCALL extension.
By the way, I think all this should go into the system PTA.

As far as I can tell, it's not trivial in that what is being suggested is registered memref-type functionality, and I don't think we have enough fields in TEE_Param, and associated structures, to make this work, at least not without changing them.

I'm thinking about it...

We can take this after this PR. It's only going to affect the ABI between TA and OP-TEE, so we can let that change with regards to OCALL for a while.

jenswi-linaro · 2020-03-23T13:12:30Z

mk/config.mk

@@ -547,3 +547,6 @@ CFG_SHOW_CONF_ON_BOOT ?= n
 # to a TA, so a TPM Service could use it to extend any measurement
 # taken before the service was up and running.
 CFG_CORE_TPM_EVENT_LOG ?= n
+
+# Enables support for OCALLs
+CFG_OCALL ?= y


I don't think _CA_ would add anything useful. The name of the feature is OCALL.
The comment describing the config could mention that this is an RPC into the Client Application.

lib/libutee/tee_api.c

jforissier · 2020-03-23T13:27:37Z

lib/libutee/arch/arm/user_ta_entry.c

@@ -255,6 +260,11 @@ static TEE_Result entry_close_session(unsigned long session_id)

 	TA_CloseSessionEntryPoint(session->session_ctx);

+#if defined(CFG_OCALL)
+	if (tee_api_ocall_session)


Could we avoid the #if (here and above) with the following? (untested):

if (IS_ENABLED(CFG_OCALL) && tee_api_ocall_session) ...

We could do this, but then we'd have to always declare tee_api_ocall_session, regardless of the value of CFG_OCALL. That is, if OCALL support is disabled, that variable would still exist. I would imagine that the linker would realize it's untouched and discard it.

Preference?

I would imagine that the linker would realize it's untouched and discard it.

Indeed, because we're using -fdata-sections and --gc-sections.
I think we should try to use IS_ENABLED() as much as possible, because it avoids #ifdef which is good for legibility and also build coverage in CI.

Done. I've also removed the #ifdef from tee_api.c.

Would you like to see IS_ENABLED for capability reporting, too?

We have there another case of a different existing style, in this case not using the macro.

core/pta/ocall.c

etienne-lms · 2020-03-24T09:49:01Z

core/pta/ocall.c

+			return TEE_ERROR_BAD_PARAMETERS;
+
+		/* Compute memory the CA must allocate for the OCALL params */
+		res = compute_required_mobj_size(ca_param_types, ca_params,


If so TA would need to allocate non-secure memory. There isn't yet any API for that. Consider a specific command of this OCALL PTA?

lib/libutee/include/tee_internal_api_extensions.h

lib/libutee/include/tee_api_defines.h

etienne-lms · 2020-03-24T10:14:22Z

core/pta/ocall.c

+					     TEE_Param params[TEE_NUM_PARAMS],
+					     size_t *required_size)
+{
+	TEE_Param *param;


generic comment: always initialize local variables where defined. See coding-standards, 3rd bullet.

Interesting. This requirement cuts both ways though: always initializing variables precludes the compiler from warning the developer when the variable is used in a location where its value should have been updated prior to the usage. I've run into a few of those in fact while writing this patch set.

From my days of working on Windows, we'd leave uninitialized variables which are expected to be filled later on. That way, if our control flow is busted and a variable is used without having been set to the expected value, the compiler would bark at us. And we compile with warnings as errors, so we'd fail the build altogether.

I'll follow the coding standards, but with reservations :) .

The rationale is that we want all variables to have a well defined value, i.e., to have the developer think about it and come up with a good value instead of having what often is a random value otherwise (static's etc are an exception). The reason why we've introduced this is because we've been bitten by a couple of security issues in the past due to uninitialized variables. As anything else, there are pros and cons.

HernanGatta · 2020-03-26T05:09:13Z

@jforissier

in the end we expect a set of properly formatted patches

All fixed up, except for this:

CHECK: Prefer using the BIT macro
#25: FILE: core/arch/arm/include/sm/optee_smc.h:280:
+#define OPTEE_SMC_SEC_CAP_OCALL			(1 << 4)

I could easily change that to BIT(4), but that wouldn't follow the style of the rest of the file.

Would you like me to fix up the rest of the file with BIT(x), or do we ignore this complaint?

jforissier · 2020-03-26T08:26:33Z

@jforissier

in the end we expect a set of properly formatted patches

All fixed up, except for this:
CHECK: Prefer using the BIT macro
#25: FILE: core/arch/arm/include/sm/optee_smc.h:280:
+#define OPTEE_SMC_SEC_CAP_OCALL			(1 << 4)
I could easily change that to BIT(4), but that wouldn't follow the style of the rest of the file.

Would you like me to fix up the rest of the file with BIT(x), or do we ignore this complaint?

I'd rather fix that too since I see no reason not to ;-) Please introduce a prior commit changing the existing defines.

jbech-linaro · 2020-03-26T08:30:49Z

@jforissier

in the end we expect a set of properly formatted patches

All fixed up, except for this:
CHECK: Prefer using the BIT macro
#25: FILE: core/arch/arm/include/sm/optee_smc.h:280:
+#define OPTEE_SMC_SEC_CAP_OCALL			(1 << 4)
I could easily change that to BIT(4), but that wouldn't follow the style of the rest of the file.
Would you like me to fix up the rest of the file with BIT(x), or do we ignore this complaint?
I'd rather fix that too since I see no reason not to ;-) Please introduce a prior commit changing the existing defines.

Also, please change it to use "5" instead of "4", since we already have other pull requests (NULL parameter support patches) in the pipe where "4" is used.

HernanGatta · 2020-03-26T21:46:54Z

The rationale is [..]

Thank for you the explanation. Seeing the security rationale in the coding standards does certainly make sense, one wouldn't want to leak stack data inadvertently.

I'd rather fix that too since I see no reason not to ;-) Please introduce a prior commit changing the existing defines.

Done.

Also, please change it to use "5" instead of "4", since we already have other pull requests (NULL parameter support patches) in the pipe where "4" is used.

Good call, done.

HernanGatta · 2020-03-26T22:58:21Z

All green, cleaning up the Linux PR next.

Outstanding issues

Do we move all this to the system PTA?
Are we all OK with the current nomenclature?
Zero-copy now or later?
Any other concerns?

My answers

Sounds fine by me.
1.1. While I'm not arguing for the following, I wonder: would anyone suggest turning this functionality into a system call seeing as TEE_InvokeTACommand is backed by one?
I am.
We could do it later for no other reason than to get the current changes moving.
3.1 Can anyone think of any risks regarding, say, backwards compatibility, or otherwise, if we wait?
I'd like to follow up as suggested about the known issue in the PR description.

jenswi-linaro · 2020-03-27T07:09:00Z

1.1. While I'm not arguing for the following, I wonder: would anyone suggest turning this functionality into a system call seeing as TEE_InvokeTACommand is backed by one?

We don't add new syscalls unless there's no other practical way.

Zero-copy now or later?

We could do it later for no other reason than to get the current changes moving.
3.1 Can anyone think of any risks regarding, say, backwards compatibility, or otherwise, if we wait?

There is the backwards compatibility issue with the ABI change, the API will remain the same the TA just needs to be recompiled or at least relinked.

I'd like to follow up as suggested about the known issue in the PR description.

Please contact me privately, [email protected] and I'll take a look.

github-actions · 2020-07-24T00:43:14Z

This pull request has been marked as a stale pull request because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this pull request will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.

jforissier · 2020-07-28T08:40:41Z

@HernanGatta do you think you can spend some more time addressing the last comments on this series? AFAICT there is not much left to do before this can be merged (and same for the other PRs: libteec, xtest and the linux driver). It would be really nice to have this in the next release (3.10.0) which is planned for August 21st.

HernanGatta · 2020-10-19T07:17:15Z

@HernanGatta do you think you can spend some more time addressing the last comments on this series? AFAICT there is not much left to do before this can be merged (and same for the other PRs: libteec, xtest and the linux driver). It would be really nice to have this in the next release (3.10.0) which is planned for August 21st.

Unfortunately, the timing on my end didn't line up. Hopefully we can get this in by 3.12.0 in January, though.

I've addressed your comments. An additional change is that I've set CFG_OCALL=n if CFG_CORE_SEL1_SPMC=y. I'm not familiar with FF-A and the corresponding build did not pass seeing as the RPC functions for memory allocation and free are reimplemented for that case in a different way.

I presume there should be a way to still support OCALLs on FF-A, though. Is it possible to emulate FF-A with QEMU?

Also, I can remove the Reviewed-by tag from core: OCALL support if you'd like another pass at this considering new changes in OP-TEE since your last look.

Thanks!

jenswi-linaro · 2020-10-21T09:34:48Z

Disabling OCALL now if FF-A is in use is OK in my opinion. FF-A is still in an experimental state. Adding OCALL support with FF-A later on when things has settled should not be hard.

jforissier

LGTM, one small concern below.

lib/libutee/tee_api.c

lib/libutee/arch/arm/user_ta_entry.c

lib/libutee/tee_api.c

jenswi-linaro · 2020-10-30T11:24:32Z

core/pta/system.c

+			buffer = (void *)(uintptr_t)up->vals[n * 2];
+			size = up->vals[n * 2 + 1];
+			if (buffer && pt != TEE_PARAM_TYPE_MEMREF_OUTPUT) {
+				destination = PTR_ADD(mobj_va, mobj_offs);


This addition may overflow or result in a buffer at least partially outside the mobj.

jenswi-linaro · 2020-10-30T11:28:59Z

core/pta/system.c

+	ocall_id = params[0].value.a;
+	ocall_up = (struct utee_params *)params[1].memref.buffer; /* User ptr */
+
+	res = ocall_check_parameters(&utc->uctx, ocall_up);


If these checks are to be effective we need to keep ocall_up in OP-TEE Core memory, not the potentially less secure TA memory.

By the way, why not combine this function with ocall_compute_mobj_size()?

jforissier · 2021-02-22T09:02:25Z

@HernanGatta ping?

etienne-lms · 2021-03-31T18:27:41Z

Hello @HernanGatta and all,
Some info on this P-R series.
I am working on SCMI support in OP-TEE where OP-TEE Core exposes system resources to REE kernel: clocks, sensors, reset controller, and few more. One can have a look at the SCMI specification.
Using OCALLs, we could provision an OP-TEE thread for SCMI message exchange between REE kernel and TEE core. I plan to create some P-Rs for this based on your work, using only the REE/TEE kernels parts and maybe not the SHM parts, and get one's feedback.
Regards

jforissier · 2021-04-01T12:32:42Z

@etienne-lms this PR was discussed in the last LOC meeting (link) and everyone agreed that it makes sense to revive this PR, so your contributions are welcome :) As mentioned in the notes, the difficult part may be related to some reference counting issue in the Linux driver patches so we concluded it would be good to start by clarifying this point.

etienne-lms · 2021-04-01T12:47:35Z

Thanks for the link :)

checkpatch suggests using the BIT macro instead of a left shift. Signed-off-by: Hernan Gatta <[email protected]> Reviewed-by: Jerome Forissier <[email protected]>

Adds the ability for TAs to perform "Out Calls", or OCALLs. OCALLs allow TAs to invoke commands on their corresponding CA in the same way that CAs can invoke commands on TAs. Also, adds a new capability that reports whether OP-TEE was built with OCALL support. Signed-off-by: Hernan Gatta <[email protected]> Reviewed-by: Jerome Forissier <[email protected]>

HernanGatta · 2021-04-08T00:50:04Z

Hello all, my apologies for the hiatus. I'm back and looking at this again, particularly the issues that were brought up regarding memory references. I'll report back with what I found. I'm glad to see functionality being implemented atop OCALLs :) .

HernanGatta · 2021-04-08T01:04:04Z

Latest push is merely a rebase. Jens' comments still to be addressed.

checkpatch suggests using the BIT macro instead of a left shift. Signed-off-by: Hernan Gatta <[email protected]> Reviewed-by: Jerome Forissier <[email protected]> [etienne: picked from OP-TEE#3673 series] Signed-off-by: Etienne Carriere <[email protected]> Change-Id: I4806c99bede5a31bf19b18eb77e86284767fd3fc Reviewed-on: https://gerrit.st.com/c/mpu/oe/optee/optee_os/+/202482 Tested-by: Etienne CARRIERE <[email protected]> Tested-by: Lionel DEBIEVE <[email protected]> Reviewed-by: Etienne CARRIERE <[email protected]> Reviewed-by: Lionel DEBIEVE <[email protected]>

Adds the ability for Core to perform "Out Calls", or OCALLs. OCALLs allow OP-TEE Core PTA services to invoke commands on their corresponding client in the same way that client can invoke commands on TAs. Adds a new capability that reports whether OP-TEE was built with OCALL support. Signed-off-by: Hernan Gatta <[email protected]> Reviewed-by: Jerome Forissier <[email protected]> [etienne: picked from OP-TEE#3673 series] [etienne: split CFG_OCALL into CFG_{CORE|USER}_OCALL, no libutee, no pta] Signed-off-by: Etienne Carriere <[email protected]> Change-Id: I410d8f5743473177f7091c6db0f9aea5fe4ce5bc Reviewed-on: https://gerrit.st.com/c/mpu/oe/optee/optee_os/+/202483 Tested-by: Etienne CARRIERE <[email protected]> Tested-by: Lionel DEBIEVE <[email protected]> Reviewed-by: Etienne CARRIERE <[email protected]> Reviewed-by: Lionel DEBIEVE <[email protected]>

checkpatch suggests using the BIT macro instead of a left shift. Signed-off-by: Hernan Gatta <[email protected]> Reviewed-by: Jerome Forissier <[email protected]> [etienne: picked from OP-TEE#3673 series] Signed-off-by: Etienne Carriere <[email protected]> Change-Id: I4806c99bede5a31bf19b18eb77e86284767fd3fc Reviewed-on: https://gerrit.st.com/c/mpu/oe/optee/optee_os/+/202482 Tested-by: Etienne CARRIERE <[email protected]> Tested-by: Lionel DEBIEVE <[email protected]> Reviewed-by: Etienne CARRIERE <[email protected]> Reviewed-by: Lionel DEBIEVE <[email protected]>

Adds the ability for Core to perform "Out Calls", or OCALLs. OCALLs allow OP-TEE Core PTA services to invoke commands on their corresponding client in the same way that client can invoke commands on TAs. Adds a new capability that reports whether OP-TEE was built with OCALL support. Signed-off-by: Hernan Gatta <[email protected]> Reviewed-by: Jerome Forissier <[email protected]> [etienne: picked from OP-TEE#3673 series] [etienne: split CFG_OCALL into CFG_{CORE|USER}_OCALL, no libutee, no pta] Signed-off-by: Etienne Carriere <[email protected]> Change-Id: I410d8f5743473177f7091c6db0f9aea5fe4ce5bc Reviewed-on: https://gerrit.st.com/c/mpu/oe/optee/optee_os/+/202483 Tested-by: Etienne CARRIERE <[email protected]> Tested-by: Lionel DEBIEVE <[email protected]> Reviewed-by: Etienne CARRIERE <[email protected]> Reviewed-by: Lionel DEBIEVE <[email protected]>

This was referenced Mar 18, 2020

driver: tee: optee: implement OCALLs linaro-swg/linux#72

Open

libteec: implement OCALLs OP-TEE/optee_client#171

Closed

ocall: add an example to show how to use OCALLs linaro-swg/optee_examples#64

Closed

Custom RPC from user TA #3303

Closed

etienne-lms reviewed Mar 20, 2020

View reviewed changes

jenswi-linaro reviewed Mar 23, 2020

View reviewed changes

jforissier reviewed Mar 23, 2020

View reviewed changes

core/pta/ocall.c Outdated Show resolved Hide resolved

etienne-lms reviewed Mar 24, 2020

View reviewed changes

HernanGatta force-pushed the optee-generic-rpc-support branch 3 times, most recently from 4008dfc to 8eaec00 Compare March 26, 2020 05:04

HernanGatta force-pushed the optee-generic-rpc-support branch 3 times, most recently from 7032624 to a269d46 Compare March 26, 2020 21:43

HernanGatta force-pushed the optee-generic-rpc-support branch 2 times, most recently from ec11de8 to b3d485f Compare March 26, 2020 22:20

HernanGatta force-pushed the optee-generic-rpc-support branch 5 times, most recently from 4b5a6b6 to c44578b Compare April 11, 2020 07:44

vchong mentioned this pull request Jul 5, 2020

Question Regarding Context Switch Between REE and TEE #3963

Closed

github-actions bot added the Stale label Jul 24, 2020

jenswi-linaro removed the Stale label Jul 24, 2020

jforissier added the enhancement label Aug 17, 2020

HernanGatta force-pushed the optee-generic-rpc-support branch 2 times, most recently from bc25eb0 to 8f56808 Compare October 19, 2020 05:54

jforissier reviewed Oct 21, 2020

View reviewed changes

lib/libutee/tee_api.c Outdated Show resolved Hide resolved

lib/libutee/arch/arm/user_ta_entry.c Outdated Show resolved Hide resolved

lib/libutee/tee_api.c Show resolved Hide resolved

HernanGatta force-pushed the optee-generic-rpc-support branch 2 times, most recently from 5eb7ef1 to 31b6a60 Compare October 29, 2020 09:07

jenswi-linaro reviewed Oct 30, 2020

View reviewed changes

etienne-lms mentioned this pull request Dec 9, 2020

core: add new PRC and PTA for loadable plugins framework #4248

Merged

etienne-lms mentioned this pull request Apr 5, 2021

[RFC] SCMI PTA with OCALL #4535

Closed

HernanGatta added 2 commits April 5, 2021 22:20

core: fix flag formatting

438d9ab

checkpatch suggests using the BIT macro instead of a left shift. Signed-off-by: Hernan Gatta <[email protected]> Reviewed-by: Jerome Forissier <[email protected]>

HernanGatta force-pushed the optee-generic-rpc-support branch from 31b6a60 to 01ba28a Compare April 8, 2021 00:58

jenswi-linaro mentioned this pull request May 28, 2021

Simplified OCALL #4650

Open

[RFC] core: implement OCALLs #3673

Are you sure you want to change the base?

[RFC] core: implement OCALLs #3673

Conversation

HernanGatta commented Mar 18, 2020 • edited Loading

Overview

The life of an OCALL

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HernanGatta commented Mar 22, 2020 • edited Loading

jforissier commented Mar 23, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HernanGatta Mar 26, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HernanGatta Mar 26, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HernanGatta Mar 26, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HernanGatta Mar 26, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HernanGatta commented Mar 26, 2020 • edited Loading

jforissier commented Mar 26, 2020

jbech-linaro commented Mar 26, 2020

HernanGatta commented Mar 26, 2020

HernanGatta commented Mar 26, 2020 • edited Loading

jenswi-linaro commented Mar 27, 2020

github-actions bot commented Jul 24, 2020

jforissier commented Jul 28, 2020

HernanGatta commented Oct 19, 2020 • edited Loading

jenswi-linaro commented Oct 21, 2020

jforissier left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jforissier commented Feb 22, 2021

etienne-lms commented Mar 31, 2021

jforissier commented Apr 1, 2021

etienne-lms commented Apr 1, 2021

HernanGatta commented Apr 8, 2021

HernanGatta commented Apr 8, 2021

HernanGatta commented Mar 18, 2020 •

edited

Loading

HernanGatta commented Mar 22, 2020 •

edited

Loading

HernanGatta Mar 26, 2020 •

edited

Loading

HernanGatta Mar 26, 2020 •

edited

Loading

HernanGatta Mar 26, 2020 •

edited

Loading

HernanGatta Mar 26, 2020 •

edited

Loading

HernanGatta commented Mar 26, 2020 •

edited

Loading

HernanGatta commented Mar 26, 2020 •

edited

Loading

HernanGatta commented Oct 19, 2020 •

edited

Loading