Copying an email exchange between me and Norman to teh mailing list. I have a few master's students who are starting to work on Trustzone, so I am trying to find out the best way to get them up and running.
Target platform is the i.MX6 Sabrelite board from Freescale. later we will move to our own open source i.MX6 board.
----------------------------------------------------------------------------------- Hello,
My student started work today. I have asked him to post on the group. I am defining the scope of work for him for the next 1 year. Basically I want him to complete the trustzone integration on the i.MX6 board. Do you think there is 6-8 months of work left for 1 person in this effort ?
the answer very much depends on the experience of the developer and degree of trustzone support you want to achieve. Given that base-hw support trustzone on the Cortex-A9 already (for the Versatile Express platform) and also the i.MX53 SoC, I don't expect any difficulties to get the TZ world switch running in principle.
If you really care about thoroughly protecting the secure world from the normal world, however, there is much more work to do. E.g., in our current demo scenario, we cut some corners, which might not be good idea in a real product. E.g. we grant the normal world access to the system-and-clock management unit. Revoking access to this unit from the normal world is easy. But to get Linux running w/o access to it is quite difficult. We'd need to either provide a virtualized version of the device (using a trap-and-emulate scheme) or change the Linux kernel to use custom smc "hypercalls" to the TZ VMM instead of accessing the device directly.
Also, as an additional challenge, it would be worthwhile to investigate a solution for the problem described in the last paragraphs of the Section "Additional device drivers" of our article:
http://genode.org/documentation/articles/trustzone#Additional_device_drivers
The DMA problem (GPU and IPU are using the same DMA channel) is quite serious. It would be interesting to investigate if i.MX6 has fixed that.
To sum it up, the task can be scaled from a few months (just experimenting with the world switch and granting most devices to the normal world) to more than a year (when revoking devices from the normal world while still making Linux happy to run in the normal world). ---------------------------------------------------------------------------------
Madhu
Norman's reply to my student Chirag.
--------------------------------------------------------------- Hello Chirag,
welcome to Genode! :-)
Everything described in the article is publicly available. You can find the links to the respective Git branches in the article. However, the work was carried out in the i.MX53.
For moving to the i.MX6 platform, I assume that Aditya Kousik has already got the base-hw kernel running on the platform, does he? So I would would go from his branch.
I recommend to first try to get acquainted with the structure of the base-hw code and investigate the i.MX53-specific code in there. The relevant portions are located at base-hw/src/core/imx53 and include/platform/imx53/drivers.
For working on the TZ world switch, you might take the run script at os/run/tz_vmm.run as starting point. The user-level TZ VMM component is located at os/src/server/tz_vmm. The interaction between the base-hw kernel and the user-level TZ VMM component happens via the so-called "VM" service provided by the core of base-hw. You can find the interface at base-hw/include/vm_session/.
Once you got the scenario described by the tz_vmm.run script running the i.MX6 platform, it would be a good time to investigate the additional patch series by Stefan (skalk) of the i.MX-tablet demo branch cited in our article:
https://github.com/skalk/genode/commits/i.MX53_tablet_demo
I hope those pointers are helpful as starting points.
That being said, I'd like to encourage you to post technical questions on our mailing list instead sending private mails to me. On the list, your questions will get the attention of more people, i.e., the engineers who have actually developed the TrustZone-related code (that wasn't me). Also, the discussions may help others in the future.
You can subscribe to the mailing list here:
http://genode.org/community/mailing-lists
Cheers and happy hacking!
Norman ----------------------------------------------------------------------------
Madhu
On Sun, May 25, 2014 at 8:36 AM, S Madhu <smadhu2048@...9...> wrote:
Copying an email exchange between me and Norman to teh mailing list. I have a few master's students who are starting to work on Trustzone, so I am trying to find out the best way to get them up and running.
Target platform is the i.MX6 Sabrelite board from Freescale. later we will move to our own open source i.MX6 board.
Hello,
My student started work today. I have asked him to post on the group. I am defining the scope of work for him for the next 1 year. Basically I want him to complete the trustzone integration on the i.MX6 board. Do you think there is 6-8 months of work left for 1 person in this effort ?
the answer very much depends on the experience of the developer and degree of trustzone support you want to achieve. Given that base-hw support trustzone on the Cortex-A9 already (for the Versatile Express platform) and also the i.MX53 SoC, I don't expect any difficulties to get the TZ world switch running in principle.
If you really care about thoroughly protecting the secure world from the normal world, however, there is much more work to do. E.g., in our current demo scenario, we cut some corners, which might not be good idea in a real product. E.g. we grant the normal world access to the system-and-clock management unit. Revoking access to this unit from the normal world is easy. But to get Linux running w/o access to it is quite difficult. We'd need to either provide a virtualized version of the device (using a trap-and-emulate scheme) or change the Linux kernel to use custom smc "hypercalls" to the TZ VMM instead of accessing the device directly.
Also, as an additional challenge, it would be worthwhile to investigate a solution for the problem described in the last paragraphs of the Section "Additional device drivers" of our article:
http://genode.org/documentation/articles/trustzone#Additional_device_drivers
The DMA problem (GPU and IPU are using the same DMA channel) is quite serious. It would be interesting to investigate if i.MX6 has fixed that.
To sum it up, the task can be scaled from a few months (just experimenting with the world switch and granting most devices to the normal world) to more than a year (when revoking devices from the normal world while still making Linux happy to run in the normal world).
Madhu
-
S Madhu