国内开源ARM TrustZone安全内核

Hi Wenhao,

Thanks for the reply, some more questions:

1. Yes. For multicore support, T6 runs in the primary CPU while Rich OS runs in all CPUs. T6 applications are scheduled by a trusted timer separately.

So it seems T6 only runs in one CPU (for example CPU0). And you have another timer FIQ triggering T6 task scheduling?

What's the relation between the Linux timer (10ms) and your FIQ timer? If T6 has lots of work to do, will it stop Linux timer IRQ?

How can other normal world task submit command to your T6 trustlet?  If other CPU wants to get service from T6, they have to place request in shared mem and submit to T6 ?

And you have a Stub thread in CPU0 waiting to get commands from other CPUs?

2. Yes, FIQ for TZ and IRQ for NW. In a uniprocessor, T6 maintains a GIC vector table for secure and normal world separately. When in secure world, only the interested interrupts are enabled, all others are disabled until switching back to normal world. Though there is a more elegant way to do this in muliprocessor, we have implemented this yet.

This is not a good design, you should turn on IRQ processing even if T6 runs in secure world.

There are many software real time requests in Linux, especially for media player etc.

3. Of course they should be protected by TZASC. And the secure peripherals, such as the trusted timer, should be set as secure by TZPC.

4. We have our own shared memory mechanism. GP TEE API is too complex to use, we take a simple way. In T6, communication between NW and SW is like IPC.

GP TEE API is very clean and simple. So how do you transfer large buffer in NW to SW using your API?

It seems that your Trustlet runs in its own address, so I assume you have some mechanism to populate SW page tables to map a Linux NW virtual address to your Trustlet virtual address..

Or you just pass physical address instead from NW to SW?

5. No, they are totally separated.

6. Yes, the trusted timer mentioned above.

Trustzone is a promising area and so far there are only few companies (Trustsonic, Dixcrex) have Trustzone solution.

I recommend you to go on working to make T6 with product ready quality.

I can't see your source code, but based on all the information, I'd suggest the following things:

1) Use GP TEE APIs , this is an industry standard,  you can't use your own proprietary APIs

2) Improve your memory management , make sure the shared memory NW/SW are well designed

3) Do not mask IRQ handling in SW, this is critical, your T6 will not be usable if you mask IRQ in SW

Thanks,

ochaoboy

Hi Wenhao,

Thanks for the reply, some more questions:

1. Yes. For multicore support, T6 runs in the primary CPU while Rich OS runs in all CPUs. T6 applications are scheduled by a trusted timer separately.

So it seems T6 only runs in one CPU (for example CPU0). And you have another timer FIQ triggering T6 task scheduling?

What's the relation between the Linux timer (10ms) and your FIQ timer? If T6 has lots of work to do, will it stop Linux timer IRQ?

How can other normal world task submit command to your T6 trustlet?  If other CPU wants to get service from T6, they have to place request in shared mem and submit to T6 ?

And you have a Stub thread in CPU0 waiting to get commands from other CPUs?

2. Yes, FIQ for TZ and IRQ for NW. In a uniprocessor, T6 maintains a GIC vector table for secure and normal world separately. When in secure world, only the interested interrupts are enabled, all others are disabled until switching back to normal world. Though there is a more elegant way to do this in muliprocessor, we have implemented this yet.

This is not a good design, you should turn on IRQ processing even if T6 runs in secure world.

There are many software real time requests in Linux, especially for media player etc.

3. Of course they should be protected by TZASC. And the secure peripherals, such as the trusted timer, should be set as secure by TZPC.

4. We have our own shared memory mechanism. GP TEE API is too complex to use, we take a simple way. In T6, communication between NW and SW is like IPC.

GP TEE API is very clean and simple. So how do you transfer large buffer in NW to SW using your API?

It seems that your Trustlet runs in its own address, so I assume you have some mechanism to populate SW page tables to map a Linux NW virtual address to your Trustlet virtual address..

Or you just pass physical address instead from NW to SW?

5. No, they are totally separated.

6. Yes, the trusted timer mentioned above.

Trustzone is a promising area and so far there are only few companies (Trustsonic, Dixcrex) have Trustzone solution.

I recommend you to go on working to make T6 with product ready quality.

I can't see your source code, but based on all the information, I'd suggest the following things:

1) Use GP TEE APIs , this is an industry standard,  you can't use your own proprietary APIs

2) Improve your memory management , make sure the shared memory NW/SW are well designed

3) Do not mask IRQ handling in SW, this is critical, your T6 will not be usable if you mask IRQ in SW

Thanks,

ochaoboy

Hi Ochaoboy,

Really helpful and valuable reply, thanks. Here are my comments:

1. T6 has two ways to handle scheduling, the first one is reserve a FIQ timer,  the second one is to use non-preemptive scheduling if you don't want to modify non-secure kernel. We put FIQ timer a higher priority that Linux timer IRQ. Communication between worlds has synchronized and asynchronized ways: invoke SMC directly or through an interrupt.

2. Maybe that is not a good design, but we sometimes got too many interrupts when switching to secure world, that is why we currently disable most of IRQs that we don't care.

4. We provide shared memory mechanism, it is Trustlet's responsibility to decide how to handle its buffers. T6 maintains the mapping of secure and non-secure memory in Trustlet's page table.

We may provide GP TEE API as an alternative lib in the future.

Currently, we are: 1) trying to remove the board specific NDA codes and refine project configuration for public download, as we could not come up with a better approach,  2) solving L2 cache issue, some parts of which needs to be initialized in secure world. It may take some days since we are busy preparing some exams...

Thanks Ochaoboy.

Thanks,

Wenhao

很好的方法，祝考试取得好成绩。

祝LZ考试得高分