Thanks a lot Jens.

I just want to make sure that, there was nothing fundamental problem for this.

My idea is to change op-tee kernel driver to pin the corresponding user-pages (i.e memref.buffer) which ensures that these will not be unmapped, before making smc and unpinning them on return.

Will submit a pull request, once I have a working version.

-Aravind ________________________________ From: Jens Wiklander jens.wiklander@linaro.org Sent: Tuesday, June 14, 2016 11:45 PM To: machiry aravind Cc: tee-dev@lists.linaro.org; Eric Gustafson Subject: Re: [Tee-dev] OP-TEE OS: Param Mapping in TA

Hi,

On Tue, Jun 14, 2016 at 11:51 PM, machiry aravind machiry_msidc@hotmail.com wrote:

Hi all,

Is there any reason, why we expect all the memref param physical address to be in MEM_AREA_NSEC_SHM?

Current design is that OP-TEE tells normal world which memory to use as shared memory, it doesn't make sense for OP-TEE to accept pointers to memory out side that range.

More specifically, why is it hard to map arbitrary non-secure user-space pages into TA?

If you want to map them, you need to make sure that they aren't unmapped (or more specifically reused for something else) while used in secure world.

MEM_AREA_NSEC_SHM restriction imposes unnecessary limit on TA.

If I want to implement some integrity checking mechanism on large sections of memory, this restriction makes it almost impossible.

Yes, but the purpose of this memory is to be used as shared memory for communication between secure and non-secure world. You're looking for something much more complex.

Long term I think we'd like to be able to map arbitrary non-secure memory as parameters for TAs, both to make some use cases more efficient but also to make MEM_AREA_NSEC_SHM optional in some configuration. I'm not aware of any concrete plans though.

Regards, Jens

________________________________ From: Jerome Forissier jerome.forissier@linaro.org Sent: Wednesday, June 15, 2016 12:30 AM To: machiry aravind Cc: Jens Wiklander; tee-dev@lists.linaro.org; Eric Gustafson Subject: Re: [Tee-dev] OP-TEE OS: Param Mapping in TA

Hi guys,

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

Thanks a lot Jens.

I just want to make sure that, there was nothing fundamental problem for this.

My idea is to change op-tee kernel driver to pin the corresponding user-pages (i.e memref.buffer) which ensures that these will not be unmapped, before making smc and unpinning them on return.

Would that be triggered by TEEC_RegisterSharedMemory() in libteec?

[Aravind] Nope, The plan is to be transparent. non-secure user space can pass any user-space pointer as buffer argument. op-tee kernel driver verifies the address, pins corresponding pages.

-- Jerome

Will submit a pull request, once I have a working version.

-Aravind ________________________________ From: Jens Wiklander <jens.wiklander@linaro.orgmailto:jens.wiklander@linaro.org> Sent: Tuesday, June 14, 2016 11:45 PM To: machiry aravind Cc: tee-dev@lists.linaro.orgmailto:tee-dev@lists.linaro.org; Eric Gustafson Subject: Re: [Tee-dev] OP-TEE OS: Param Mapping in TA

Hi,

On Tue, Jun 14, 2016 at 11:51 PM, machiry aravind <machiry_msidc@hotmail.commailto:machiry_msidc@hotmail.com> wrote:

Hi all,

Is there any reason, why we expect all the memref param physical address to be in MEM_AREA_NSEC_SHM?

Current design is that OP-TEE tells normal world which memory to use as shared memory, it doesn't make sense for OP-TEE to accept pointers to memory out side that range.

More specifically, why is it hard to map arbitrary non-secure user-space pages into TA?

If you want to map them, you need to make sure that they aren't unmapped (or more specifically reused for something else) while used in secure world.

MEM_AREA_NSEC_SHM restriction imposes unnecessary limit on TA.

If I want to implement some integrity checking mechanism on large sections of memory, this restriction makes it almost impossible.

Yes, but the purpose of this memory is to be used as shared memory for communication between secure and non-secure world. You're looking for something much more complex.

Long term I think we'd like to be able to map arbitrary non-secure memory as parameters for TAs, both to make some use cases more efficient but also to make MEM_AREA_NSEC_SHM optional in some configuration. I'm not aware of any concrete plans though.

Regards, Jens

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

________________________________ From: Jerome Forissier jerome.forissier@linaro.org Sent: Wednesday, June 15, 2016 12:45 AM To: machiry aravind Cc: Jens Wiklander; tee-dev@lists.linaro.org; Eric Gustafson Subject: Re: [Tee-dev] OP-TEE OS: Param Mapping in TA

On Wed, Jun 15, 2016 at 9:34 AM, machiry aravind <machiry_msidc@hotmail.commailto:machiry_msidc@hotmail.com> wrote:

________________________________ From: Jerome Forissier <jerome.forissier@linaro.orgmailto:jerome.forissier@linaro.org> Sent: Wednesday, June 15, 2016 12:30 AM To: machiry aravind Cc: Jens Wiklander; tee-dev@lists.linaro.orgmailto:tee-dev@lists.linaro.org; Eric Gustafson Subject: Re: [Tee-dev] OP-TEE OS: Param Mapping in TA

Hi guys,

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

Thanks a lot Jens.

I just want to make sure that, there was nothing fundamental problem for this.

My idea is to change op-tee kernel driver to pin the corresponding user-pages (i.e memref.buffer) which ensures that these will not be unmapped, before making smc and unpinning them on return.

Would that be triggered by TEEC_RegisterSharedMemory() in libteec?

[Aravind] Nope, The plan is to be transparent. non-secure user space can pass any user-space pointer as buffer argument. op-tee kernel driver verifies the address, pins corresponding pages.

While it sounds quite convenient, I'm afraid it can encourage the development of non-GP-compliant applications.

[Aravind] I agree. But, IMHO, GP is way too-restrictive. I do not know if it is possible to submit a RFC.

-- Jerome