FROM: http://blog.csdn.net/hovan/article/details/42674055
from My Opinion on trust zone You know, trustzone-enabled chips run in two worlds.
Ordinary world, security world, corresponding to Qualcomm here is HLOS,QSEE.
The following picture:
Here are the HLOS and QSEE software Framework chart
HLOS is divided into kernel layer and user layer. The user layer starts the app on trustzone through the API provided by qseecom.
In addition to providing API s, qseecom driver also calls scm functions for world switching.
When the scm driver receives a call from qseecom, it puts HLOS-related data (including instruction parameters) into its buffer, and then executes the scm call.
qsapp accepts requests from HLOS through the api provided by qsee and returns the execution results to HLOS.
In addition to providing API s, qsee also passes data from HLOS to qsapp from monitor, and then returns data from qsapp to HLOS.
The monitor doesn't need to say that it handles shared buffer s as well as switching the world.
It's a rough sketch. The details are rather complicated and there is no open source.
The whole invocation process is illustrated by a simple qseecom_security_test code.
The following picture:
qseecom_security_test.c
Initialize the global variable g_qseeCommHandles first
Initialize a barrier signal variable for synchronization at thread creation
Then call the pthread_create() function to create the test_thread thread thread, which will start QSApp.
Follow to the test_thread thread thread
Call the QSEECom_start_app() function to start QSApp.
This function is implemented in kernel as follows:
qseecom.c
Get shared buf fd, for communication with the security world
Call scm_call() to get into the safe world.
scm_call() is implemented as follows:
arch/arm/mach-msm/scm.c
The implementation of scm_call_common is as follows:
_ scm_call is implemented as follows:
smc is implemented as follows:
QSApp is an assembler. Well, QSApp in the safe world is running. When QSApp completes the corresponding service, it will return the data. This function will return.
Starting QSApp has been completed. Now register listener, which is used to listen for requests from QSApp. Because sometimes QSApp also needs HLOS to do something.
The realization is as follows:
This function is longer, simplify it, step by step.
First, call the QSEECom_register_listener() function to register the listener and tell QSApp that I can receive your application.
If you see the for loop again, it's waiting for the message from QSApp, but if there's a message from QSEECom_reveive_req, it's returned, and then it's processed here.
Then call qSEECom_send_resp() to send the response to QSApp.
Whether starting QSApp or registering listener is executed in threads, once all threads exit, the QSEECom_shutdown_app() function is called to stop QSApp.
The whole process is completed. As follows:
Note: The functions at the beginning of QSEECom_XX are implemented in qseecom.c of kernel, and the system calls of SCM are implemented in scm.c.
HLOS user layer grasps QSEEComAPI.h file
HLOS kernel layer grasps qseecom.c and scm.c files
Thank you