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

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

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)?

-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://avatars1.githubusercontent.com/u/1218510?v=3&s=400]https://github.com/Machiry/optee_os

Machiry/optee_oshttps://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://avatars3.githubusercontent.com/u/1218510?v=3&s=200]https://github.com/Machiry/optee_os/commit/b7f301a0dde02056f383f2415fcc7613d88ae211

Update tee_mmu.c · Machiry/optee_os@b7f301ahttps://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.commailto: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.orgmailto:david.brown@linaro.org> Sent: Monday, June 20, 2016 7:13:05 AM To: machiry aravind; tee-dev@lists.linaro.orgmailto: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.commailto: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.orgmailto:Tee-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/tee-dev

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.commailto: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.orgmailto:tee-dev-bounces@lists.linaro.org> on behalf of machiry aravind <machiry_msidc@hotmail.commailto:machiry_msidc@hotmail.com> Sent: Tuesday, June 21, 2016 4:30:40 PM To: David Brown; tee-dev@lists.linaro.orgmailto: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://avatars1.githubusercontent.com/u/1218510?v=3&s=400]https://github.com/Machiry/optee_os

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

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

[https://avatars3.githubusercontent.com/u/1218510?v=3&s=200]https://github.com/Machiry/optee_os/commit/b7f301a0dde02056f383f2415fcc7613d88ae211

Update tee_mmu.c · Machiry/optee_os@b7f301ahttps://github.com/Machiry/optee_os/commit/b7f301a0dde02056f383f2415fcc7613d88ae211 github.comhttp://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.orgmailto:david.brown@linaro.org> Sent: Tuesday, June 21, 2016 11:27:18 AM To: machiry aravind; tee-dev@lists.linaro.orgmailto: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.commailto: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.orgmailto:david.brown@linaro.org> Sent: Monday, June 20, 2016 7:13:05 AM To: machiry aravind; tee-dev@lists.linaro.orgmailto: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.commailto: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.orgmailto:Tee-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/tee-dev

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

I am taking about TEEC_MEMREF_TEMP_INPUT/TEEC_MEMREF_TEMP_OUTPUT param types.

Ideally, same physical memory should be mapped as R(for param 0) and RW(for param 1).

There could be optimizations done here to avoid a duplicate mapping and use a single RW mapping.

-Best,

Aravind

________________________________ From: Jens Wiklander jens.wiklander@linaro.org Sent: Wednesday, June 22, 2016 2:23:21 AM To: machiry aravind Cc: David Brown; tee-dev@lists.linaro.org Subject: Re: [Tee-dev] OPTEE OS : Param type not respected in mapping

On Wed, Jun 22, 2016 at 10:53 AM, machiry aravind <machiry_msidc@hotmail.commailto:machiry_msidc@hotmail.com> wrote:

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.

Write only memory is impossible on ARM (it's also an old joke :-) ). I see how this can help catching bad TAs, but it doesn't affect the integrity of secure world.

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)

From what I understand are the Read and Write attributes something an implementation can use to emulate shared memory. GP doesn't require everything to be RW.

Let's say that some shared memory is supplied as input in parameter 0 and output in parameter 1, how should the memory be mapped?

Or are we only talking about the TEEC_MEM_INPUT and TEEC_MEM_OUTPUT flags for a shared memory object? In this case I guess we should refuse using it as anything but an input parameter and there can be not conflicts. Unless the same memory is registered twice with different flags, I don't see anything in the TEE Client spec prohibiting that.

Regards, Jens

-Best, Aravind

________________________________ From: Jens Wiklander <jens.wiklander@linaro.orgmailto:jens.wiklander@linaro.org> Sent: Wednesday, June 22, 2016 1:05 AM To: machiry aravind Cc: David Brown; tee-dev@lists.linaro.orgmailto: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.commailto: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.orgmailto:tee-dev-bounces@lists.linaro.org> on behalf of machiry aravind <machiry_msidc@hotmail.commailto:machiry_msidc@hotmail.com> Sent: Tuesday, June 21, 2016 4:30:40 PM To: David Brown; tee-dev@lists.linaro.orgmailto: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://avatars1.githubusercontent.com/u/1218510?v=3&s=400]https://github.com/Machiry/optee_os

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

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

[https://avatars3.githubusercontent.com/u/1218510?v=3&s=200]https://github.com/Machiry/optee_os/commit/b7f301a0dde02056f383f2415fcc7613d88ae211

Update tee_mmu.c · Machiry/optee_os@b7f301ahttps://github.com/Machiry/optee_os/commit/b7f301a0dde02056f383f2415fcc7613d88ae211 github.comhttp://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.orgmailto:david.brown@linaro.org> Sent: Tuesday, June 21, 2016 11:27:18 AM To: machiry aravind; tee-dev@lists.linaro.orgmailto: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.commailto: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.orgmailto:david.brown@linaro.org> Sent: Monday, June 20, 2016 7:13:05 AM To: machiry aravind; tee-dev@lists.linaro.orgmailto: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.commailto: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.orgmailto:Tee-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/tee-dev

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

Hi Jens,

I am trying to implement a memory integrity checking TA, for which I need to make sure that INPUT params are mapped R only.

I could map RW but want to see if R only mapping is possible.

-Best,

Aravind

________________________________ From: Jens Wiklander jens.wiklander@linaro.org Sent: Wednesday, June 22, 2016 3:47:18 AM To: machiry aravind Cc: David Brown; tee-dev@lists.linaro.org Subject: Re: [Tee-dev] OPTEE OS : Param type not respected in mapping

On Wed, Jun 22, 2016 at 12:34 PM, machiry aravind <machiry_msidc@hotmail.commailto:machiry_msidc@hotmail.com> wrote:

I am taking about TEEC_MEMREF_TEMP_INPUT/TEEC_MEMREF_TEMP_OUTPUT param types.

Ideally, same physical memory should be mapped as R(for param 0) and RW(for param 1).

There could be optimizations done here to avoid a duplicate mapping and use a single RW mapping.

If you would do such optimizations, what's the point with all this?

Just to be clear what you're trying to achieve, what's the point of ever mapping it as read-only?

Regards, Jens

-Best,

Aravind

________________________________ From: Jens Wiklander <jens.wiklander@linaro.orgmailto:jens.wiklander@linaro.org> Sent: Wednesday, June 22, 2016 2:23:21 AM

To: machiry aravind Cc: David Brown; tee-dev@lists.linaro.orgmailto:tee-dev@lists.linaro.org Subject: Re: [Tee-dev] OPTEE OS : Param type not respected in mapping

On Wed, Jun 22, 2016 at 10:53 AM, machiry aravind <machiry_msidc@hotmail.commailto:machiry_msidc@hotmail.com> wrote:

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.

Write only memory is impossible on ARM (it's also an old joke :-) ). I see how this can help catching bad TAs, but it doesn't affect the integrity of secure world.

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)

From what I understand are the Read and Write attributes something an implementation can use to emulate shared memory. GP doesn't require everything to be RW.

Let's say that some shared memory is supplied as input in parameter 0 and output in parameter 1, how should the memory be mapped?

Or are we only talking about the TEEC_MEM_INPUT and TEEC_MEM_OUTPUT flags for a shared memory object? In this case I guess we should refuse using it as anything but an input parameter and there can be not conflicts. Unless the same memory is registered twice with different flags, I don't see anything in the TEE Client spec prohibiting that.

Regards, Jens

-Best, Aravind

________________________________ From: Jens Wiklander <jens.wiklander@linaro.orgmailto:jens.wiklander@linaro.org> Sent: Wednesday, June 22, 2016 1:05 AM To: machiry aravind Cc: David Brown; tee-dev@lists.linaro.orgmailto: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.commailto: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.orgmailto:tee-dev-bounces@lists.linaro.org> on behalf of machiry aravind <machiry_msidc@hotmail.commailto:machiry_msidc@hotmail.com> Sent: Tuesday, June 21, 2016 4:30:40 PM To: David Brown; tee-dev@lists.linaro.orgmailto: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://avatars1.githubusercontent.com/u/1218510?v=3&s=400]https://github.com/Machiry/optee_os

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

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

[https://avatars3.githubusercontent.com/u/1218510?v=3&s=200]https://github.com/Machiry/optee_os/commit/b7f301a0dde02056f383f2415fcc7613d88ae211

Update tee_mmu.c * Machiry/optee_os@b7f301ahttps://github.com/Machiry/optee_os/commit/b7f301a0dde02056f383f2415fcc7613d88ae211 github.comhttp://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.orgmailto:david.brown@linaro.org> Sent: Tuesday, June 21, 2016 11:27:18 AM To: machiry aravind; tee-dev@lists.linaro.orgmailto: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.commailto: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.orgmailto:david.brown@linaro.org> Sent: Monday, June 20, 2016 7:13:05 AM To: machiry aravind; tee-dev@lists.linaro.orgmailto: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.commailto: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.orgmailto:Tee-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/tee-dev

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