Hi Jens,

Thank you.

However, IMHO, we need to change this parameter copying, this prevents from having R or W only pages in case of INPUT or OUTPUT params respectively.

As of now, as I mentioned before all memory params are mapped RW. (I am not sure if this is also a requirement from GP TEE Internal Core specification)

-Best,
Aravind

---

From: Jens Wiklander <jens.wiklander@linaro.org>
Sent: Wednesday, June 22, 2016 1:05 AM
To: machiry aravind
Cc: David Brown; tee-dev@lists.linaro.org

Subject: Re: [Tee-dev] OPTEE OS : Param type not respected in mapping

 

Hi Aravind,

On Wed, Jun 22, 2016 at 9:06 AM, machiry aravind <machiry_msidc@hotmail.com> wrote:

Hi David,

I figured out why the tests are failing, this is because of function: tee_svc_copy_param, this copies all the parameters to secure DDR sequentially.

It computes the total size required for all parameters, does tee_mm_alloc to allocate secure DDR memory of corresponding size.

Later, it copies the contents to the newly allocated buffer. This newly allocated buffer is not page aligned and results in all parameters in same page.

This results in failure when parameters have conflicting attributes.

Following is an illustration of this issue:

NS passes parameters to TA1:

  {0x7fe01000, 16, R} {0x7fe02000, 16, RW}

TA1 receives (after optee-mapping):

  {0x200000, 16, R} {0x202000, 16, RW}

TA1 invokes via syscall_invoke_ta_command TA2 with params :

   {0x200000, 16, R} {0x202000, 16, RW}

Here, in syscall_invoke_ta_command which calls tee_svc_copy_param, following new parameters gets created:

  {0x7e03e000, 16, R} {0x7e03e010, 16, RW}  (Note that **both addrs belong to same page**)

TA2 will receive following parameters:

  {0x7e03e000, 16, R} {0x7e03e010, 16, RW} and fails during mapping.

Why do we make additional copy of the params to secure ddr in syscalls? Are there any concerns in just mapping the params (the same way we do in NS->TA)?

This is not done in all syscalls, only the ones passing memory buffers to another TA in order to protect the caller from the callee. This is more or less a requirement from GP TEE Internal Core specification.

Regards,

Jens

-Best,

Aravind

---

From: Tee-dev <tee-dev-bounces@lists.linaro.org> on behalf of machiry aravind <machiry_msidc@hotmail.com>
Sent: Tuesday, June 21, 2016 4:30:40 PM
To: David Brown; tee-dev@lists.linaro.org

Subject: Re: [Tee-dev] OPTEE OS : Param type not respected in mapping

 

My fork of optee-os: https://github.com/Machiry/optee_os

Machiry/optee_os github.com optee_os - Trusted side of the TEE

Changes made: https://github.com/Machiry/optee_os/commit/b7f301a0dde02056f383f2415fcc7613d88ae211

Update tee_mmu.c · Machiry/optee_os@b7f301a github.com Readonly mappings for INPUT params.

After looking into failing tests, it looks like all failing tests(Ex: 1011) communicate with TA (ex: rpc_test) do Inter-TA calls.  I looked into open_ta_session syscall, However, I am unable to find anything wrong.

---

From: David Brown <david.brown@linaro.org>
Sent: Tuesday, June 21, 2016 11:27:18 AM
To: machiry aravind; tee-dev@lists.linaro.org
Subject: Re: [Tee-dev] OPTEE OS : Param type not respected in mapping

 

BTW, if you want to put your code up somewhere visible, and I try it out and see if I can tell what might be going wrong.

David

On Mon, Jun 20, 2016 at 2:39 PM machiry aravind <machiry_msidc@hotmail.com> wrote:

Thanks David.

Compiler optimization seems to be a valid case, but it is interesting to note that although we can have W only pages, we cannot do it because of compiler optimizations.

I changed mapping to map output param to RW,  more test cases pass this time :)

However, If I map input param to R only, few test cases still fail.

I do not think multiple parameters can share the same page.

The shared buffer allocated by linux tee-driver is always page aligned: https://github.com/linaro-swg/linux/blob/optee/drivers/tee/tee_shm_pool.c#L126

and linux kernel api will always allocate a different shared buffer for each of the parameter:

https://github.com/OP-TEE/optee_client/blob/master/libteec/src/tee_client_api.c#L144

Also, I checked the failing test cases (ex: 1011) , I do not see anything wrong.

On TEE side, I expected to see an abort and put a break point in abort handler, but it is never hit.

---

From: David Brown <david.brown@linaro.org>
Sent: Monday, June 20, 2016 7:13:05 AM
To: machiry aravind; tee-dev@lists.linaro.org
Subject: Re: [Tee-dev] OPTEE OS : Param type not respected in mapping

 

I'm curious what happens if you try using RW for output as well. The compiler will sometimes need to read data in order to write to it.

I guess the other concern I'd have, without looking at it too much, is there a case where multiple parameters share the same page?

David

On Mon, Jun 20, 2016 at 12:12 AM machiry aravind <machiry_msidc@hotmail.com> wrote:

Hi all,

In optee-os, memory of all params is mapped RW, irrespective of paramType (viz, INPUT, OUTPUT or INOUT).

References:

https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/mm/tee_mmu.c#L394 and

https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/mm/tee_mmu.c#L62

Do we know why is this so?

I tried to change this to map R only for input, W for output and RW for inout.

However few tests (ex: 4001 - 4007) in xtest suite fails.

_______________________________________________
Tee-dev mailing list
Tee-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/tee-dev

_______________________________________________
Tee-dev mailing list
Tee-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/tee-dev