TrustZone: forcing instant switch from secure to normal world?

[Stefan Kalkowski]

Hi David,

On 06/26/2015 03:57 PM, David Goltzsche wrote:
> Hi Genode team & list,
> 
> in my master's thesis I built a framework, which enables
> cross-world-communication between the normal and secure world. This was
> based on your tz_vmm demo. If this sounds familiar: I already posted a
> few questions on this list related to my thesis ;)
> 
> My framework relied on periodic world switches triggered by Genode's
> scheduler (The normal world is running within a Genode thread, so the
> scheduler prevents both worlds from starving). Of course, simply waiting
> for world switches leads to high latencies and a low throughput.
> 
> To speed things up, we already improved the communication from normal to
> secure world: The normal world instantly hands over control to the
> secure world utilizing the smc instruction, when a message is available.
> We extended the hypercall handler in the Vmm class to notify the
> receiver via a semaphore.
> 
> Unfortunately, forcing a world switch from secure to normal world does
> not seem to be that easy: Genode's monitor mode implementation cannot
> handle entries from the secure world. Hence, usage of the smc
> instruction is not possible.

Giving control from the VMM to the normal world is pretty simple by
calling "run" on the VM session interface. Of course, it doesn't
guarantee that the kernel's scheduler immediately switches to the normal
world, depending on the current workload of the machine.  Anyway, I
think what you are trying to bypass is the guest OS' scheduler, and
forcing to deliver your signal directly to your corresponding kernel
module. This can be achieved relatively simple, as you as VMM developer
have full control regarding the normal world's machine state.

> 
> So, my approach would be using software interrupts which sould be routed
> to the normal world. I played around with the svc (supervisor call)
> instruction, but I don't know how to route this to the secure world.

Indeed, this seems to be the most promising approach triggering a
software interrupt on the secure side, and handle it in the normal
world. Everything that needs to be done is marking a designated SPI (ARM
terminology for software-triggered IRQ) as a non-secure interrupt, and
delegate that interrupt to your kernel module within the guest OS.
Moreover, you will need to extend the VM session interface with the
ability to trigger that designated "TrustZone interrupt", as the
user-level VMM is not able to access the interrupt controller directly,
which has to be done by the kernel itself.

I do not really understood your sentences regarding the supervisor call.

Best Regards
Stefan
> 
> Any hints?
> 
> Thanks in advance
> David
> 

-- 
Stefan Kalkowski
Genode Labs

http://www.genode-labs.com/ · http://genode.org/