Hello,
Thank you for the advice. I performed some checks to see in what exact mode the 'smc' instruction is executed and it is supervisor mode which is a privileged mode so no problems there. This leads me to believe there is indeed something which goes wrong with the instruction itself. Since I do not have access to a JTAG debugger, trying to find out what kind of exceptions are taken seems to be the best course of action.
As for what stop means, it is literally just that, it stops. I get all the output I would expect right up to the point where the 'smc' instruction is issued. After that, nothing happens. At least not in the normal world since I have tried running a different thread next to the one that performs the hypercall. This secondary thread should periodically print some output but remains silent all the time. The secure world does not give any signs of life either which is the main reason I'm posting here.
As far as I can see, this non responsiveness from the secure world may make it hard to get the base-hw kernel that's running there to actually see what exception is taken but I'll give it a shot.
And I am using 2 different genode kernels in the secure and normal world. The normal kernel is treated like the Linux kernel in the tz_vmm example. I simply manually place the binary image of the kernel in the bin folder so the run script can package it with the secure kernel.
Best regards, Vincent
On 03/12/2015 07:48 AM, Stefan Kalkowski wrote:
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@...52... https://lists.sourceforge.net/lists/listinfo/genode-main
-- Stefan Kalkowski Genode Labs