If you really need to execute code in monitor mode (I wonder why), I
think it will be best to create an explicit interface on the
kernel/core level that can be called from the VMM component, maybe an
extensions of the VM session interface.
I think it somehow depends on what you are trying to do. If your
routine has to be called every time a secure monitor call was
executed, it is better to handle that directly within the
Vm::exception function. If you have a very special device that needs
to be accessed from secure, privileged/monitor mode you should extend the
interface of kernel/core.
Your are welcome. Maybe, you can give us some insights why do you need
to enter monitor mode at all?
Hi Mauricio,
On Wed, Mar 28, 2018 at 07:48:43PM -0700, Mauricio Gutierrez wrote:
> Hello,
>
> I have been doing some work with the Genode Trustzone VMM scenario on my
> i.MX53 development board and I am having a bit of trouble understanding how
> the SMC calls work between the normal and secure world. Online you talk
> about how you implemented 6 calls in the modified normal world linux kernel
> but in the main for the tz_vmm I only found 4 different cases in the
> _handle_smc() function. In any case, I wanted to add my own call and was
> able to add it and check that the required arguments are passed correctly
> and everything so that part I think I understand.
>
> However, I need to do some of the handling in Monitor Mode and my
> understanding was that an SMC would throw your into monitor mode but it
> seems the handler operates in user mode? Since it is not privileged then I
> am not able to call a "cps #22" to switch to monitor mode. In an earlier
> thread I know you refer to the
>
> section "World switch between non-secure world and secure
> > world" in http://genode.org/documentation/articles/ .trustzone
>
> But I am still uncertain as to how I could get my case in _handle_smc() to
> enter monitor mode so that I can play around with the NS bit without
> leaving secure world.
You are right, our virtual-machine monitor is an unprivileged
user-level component. Because driving the normal world is not
crucial to other components inside the secure world, there is no need
to make them dependent on complex emulation/para-virtualization code inside
the kernel. That is why the kernel contains a slim
exception-vector-only functionality that is used to copy over the
normal world state to the VMM user-level component. This
exception-vector code is entered, e.g., when doing a "smc" call and
can be found here:
repos/base-hw/src/core/spec/arm_v7/trustzone/exception_ vector.s
That assembly code is the only code executed in monitor mode. In the
end it switches to secure world's supervisor mode and enters the
normal kernel routine. However, it hits subsequently some C++ VMM
kernel object routine here:
repos/base-hw/src/core/spec/arm_v7/trustzone/kernel/vm.cc
Namely, the Vm::exception function, which informs the kernel scheduler
to exclude the normal world for now, and signals the VMM user-level
component that the normal world's state changed.
> I have been studying what happens when I call an smc, say "smc #4" from
> normal world. But I have not been able to exactly pin point, where is the
> entry point for such an exception in the Genode secure world call? What
> exactly happens once I make that call to secure world and where I can I
> find/follow the code? Is this covered somewhere in your book?
>
> I know about the mode_transitions.s file as well as the exception_vector.s
> and vm.cc files in repos/base-hw/src/core/spec/arm_v7/trustzone, it seems If you really need to execute code in monitor mode (I wonder why), I
> this is the entry point? But where does it go after we call the
> nonsecure_to_secure transition?
>
> Most importantly, I need to understand where is the code operating in
> monitor mode? Where does it end and where does it start? How can I tell? If
> I needed to write at least some part of my smc handler in monitor mode
> before it switches out, what is the best approach to doing that?
>
think it will be best to create an explicit interface on the
kernel/core level that can be called from the VMM component, maybe an
extensions of the VM session interface.
I think it somehow depends on what you are trying to do. If your
routine has to be called every time a secure monitor call was
executed, it is better to handle that directly within the
Vm::exception function. If you have a very special device that needs
to be accessed from secure, privileged/monitor mode you should extend the
interface of kernel/core.
> I apologize for all the questions and would appreciate any help and
> guidance you can provide.
Your are welcome. Maybe, you can give us some insights why do you need
to enter monitor mode at all?
Best regards
Stefan
>
> Thank you,
>
> Mauricio
> ------------------------------------------------------------ ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> genode-main mailing list
> genode-main@...449...2...net
> https://lists.sourceforge.net/lists/listinfo/genode-main
--
Stefan Kalkowski
Genode labs
https://github.com.skalk | https://genode.org
------------------------------------------------------------ ------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
genode-main@...172...net
https://lists.sourceforge.net/lists/listinfo/genode-main