Thank you for the suggestion Jens. I will investigate it.


W.r.t Virtualization, We were worried about re-directing syscalls between guests.


We though of using OP-TEE TZ because of the existing support for RPC into REE, which we though could be modified to redirect the syscalls.

From: Jens Wiklander <jens.wiklander@linaro.org>
Sent: Tuesday, December 6, 2016 12:06:20 AM
To: machiry aravind
Cc: tee-dev@lists.linaro.org
Subject: Re: [Tee-dev] Isolated Execution Environment using OP-TEE TZ
 
On Tue, Dec 6, 2016 at 8:38 AM, machiry aravind
<machiry_msidc@hotmail.com> wrote:
> Hi Jens,
>
>
> By untrusted kernel, I meant the REE.
>
>
> We are trying to achieve the following:
>
>
> Lets say, we have an encrypted REE application (say EA). The vendor of the
> application wants to hide their code against potentially compromised REE
> (For example: infected with rootkit/malware).
>
> , a theoretical solution (assuming TEE is safe) would be to decrypt and
> execute the EA in TEE and proxy all the syscalls made by the EA to REE.
>
>
> While processing syscalls, REE can see only certain memory pages(decided by
> the EA and enforced by TEE).
>
>
> This way, the decrypted code of the EA, will never leave secure memory.
>
>
> tl;dr Kinda DRM for code.
>

It sounds like a lot of work to get it working, and then there's also
the limited amount of resources in secure world. I'd try to solve it
with virtualization instead.

Thanks,
Jens

>
> -Aravind
>
> ________________________________
> From: Jens Wiklander <jens.wiklander@linaro.org>
> Sent: Monday, December 5, 2016 11:16:40 PM
> To: machiry aravind
> Cc: tee-dev@lists.linaro.org
> Subject: Re: [Tee-dev] Isolated Execution Environment using OP-TEE TZ
>
> Hi Aravind,
>
> On Mon, Dec 5, 2016 at 9:41 PM, machiry aravind
> <machiry_msidc@hotmail.com> wrote:
>> Hi all,
>>
>>
>> Can we have isolated execution environments for untrusted applications
>> using
>> TrustZone?
>>
>>
>> In theory, the untrusted app will run as a TA, all syscalls made by the TA
>> will be proxyed to untrusted kernel.
>>
>
> What is the untrusted kernel?
>
>>
>> The memory mappings should be taken care so that the untrusted kernel can
>> access the isolated app's memory during syscall.
>>
>>
>> Of course, I am omitting various other details for this message.
>>
>>
>> But, is this feasible? Are there limitations on the maximum amount of
>> secure
>> memory? or Am I missing something obvious (Most likely)?
>>
>
> What are you trying to achieve?
>
> There exists other solutions based on virtualization to contain
> untrusted code, TrustZone is not the right tool for this.
>
> Thanks,
> Jens