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