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 https://github.com/Machiry/optee_os Machiry/optee_os https://github.com/Machiry/optee_os github.com optee_os - Trusted side of the TEE
Changes made: https://github.com/Machiry/optee_os/commit/b7f301a0dde02056f383f2415fcc7613d...
https://github.com/Machiry/optee_os/commit/b7f301a0dde02056f383f2415fcc7613d88ae211 Update tee_mmu.c · Machiry/optee_os@b7f301a https://github.com/Machiry/optee_os/commit/b7f301a0dde02056f383f2415fcc7613d88ae211 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#L1...
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_ap...
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#L3... and
https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/mm/tee_mmu.c#L6...
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