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.

-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

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