Hello Vincent,
On 03/11/2015 08:44 PM, Vincent Raes wrote:
Hello,
I am facing some issues with the 'SMC' instruction on the i.mx6. I can run the tz_vmm example, based on the veax9 code since they both have a TZASC, on the board and the world switch from secure to normal world works as intended. However when trying to switch back from normal world to secure world, execution simply hangs after the 'smc' assembler instruction. It was my understanding that this instruction should trap to the secure world and then the tz_vmm continues to work with that. In my case everything simply stops.
That is right, the 'smc' instruction should provoke an exception taken to the secure world's exception vector. Are you sure that the instruction is executed in the normal world? What does stop mean? To get a picture what is going on you either need to debug it via a JTAG debugger, or by instrumenting the base-hw kernel of the secure-side to see what kind of exceptions are taken. A good starting-point would be the 'Kernel::Vm' class' 'exception' function. In Genode 15.02 you can find this function in here:
https://github.com/genodelabs/genode/blob/master/repos/base-hw/src/core/spec...
If you use another version, you have to grep for it.
I am using Genode in both normal and secure world since I'm mainly going for a proof of concept at this point. In order to execute the 'smc' instruction, I implemented a public syscall so the kernel will be the one to give the command which should ensure that the processor is in a privileged mode when completing the call.
Should I perhaps add a new core service to base-hw to make the call to the kernel? And if so, are there any pointers as to how to go about this? The only real advantage this method offers as far as I can see is that it is better for Genode's access control policy and gives more control to which applications can call for the 'smc' instruction.
The other possibility why it doesn't work would be that the 'smc' instruction is not really executed in privileged mode. To be really sure about it, you might print the CPSR register and have a look at the five least-significant bits to validate the current mode.
Having a public syscall that is not private to core should not be the problem in here. That is more a question of the desired architecture, but it should function in both ways.
Just out of curiosity: if you use Genode on both sides of the TrustZone, do you use one and the same kernel/core for both worlds? And if so, how do you distinguish between both when booting the kernel?
Regards Stefan
Best regards, Vincent
Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main