先来整个图
前面我写了一篇文章是关于怎么创建CA的，然后交作业给老师了，搞忘备份了。我在做TA动态验证的时候呢，写了关于TA和CA的概念，以及CA和TA会话的创建，以及TA的加密、签名与解密、验签。
到这里，咱们应该是已经具备对了对于CA与TA两者之间的关系与CA、TA本身的东西有所了解了。在CA和TA建立连接的时候，是使用了GP中定义的TEE Client API。在TA于TEEOS通信的时候，是使用到了TEE Internal APIs。
本篇文章来记录学习图中tee-supplicant。
内容全部参考来自《手机安全和可信应用开发指南》
1、tee-supplicant是什么？
这个其实就是一个进程，是让TEEOS能够通过它来访问REE侧的资源，比如前面我讲过动态TA就是放在REE侧的文件系统里面的，还有对REE侧数据库的操作，对EMMC中RPMB分区的操作，提供socket通信等。
其源代码在optee_client/tee-supplicant目录中。编译之后会生成一个名为tee_supplicant的可执行文件，该可执行文件在REE启动时会作为一个后台守护程序被自动启动。
2、tee-supplicant怎么用？
在编译optee-client目标时，会生成一个tee_supplicant的可执行文件。在linux启动的时候，tee_supplicant就会在后台运行起来。启动的动作在build/init.d.optee文件中：
在编译时，init.d.optee文件将会被打包到根文件系统中并以optee名字存放在/etc/init.d目录中，而且会被链接到/etc/rc.d/S09_optee文件。
这些操作是在编译生成rootfs时进行的，详细情况可查看build/common.mk文件中filelist-tee-common目标的内容。系统启动tee_supplicant的过程如图所示。
(Linux系统中的根文件系统，Root FileSystem，简称为rootfs；例如，存放可执行程序的目录/bin,/sbin；存放配置文件的目录/etc；存放用户数据的目录/home；存放外设驱动信息的/dev;存放进程信息的/proc等等。rootfs，其实就是，针对特定的操作系统的架构，一种实现的形式；具体表现为，特定的文件夹，文件夹之间的关系，即组织架构，以及特定的各种文件；)
3、tee-supplicant源码啥样？
tee_supplicant作为Linux中的一个守护进程，起到处理RPC请求的服务器端的作用，通过类似于C/S的方式，为OP-TEE提供对REE侧资源进行操作的实现。
3.1 入口函数
该可执行文件的入口函数存放在optee_client/tee-supplicant/src/tee_supplicant.c文件中。
（前面我们说了加载动态TA的请求就是通过RPC实现的）
（守护进程(daemon)是一类在后台运行的特殊进程，用于执行特定的系统任务。很多守护进程在系统引导的时候启动，并且一直运行直到系统关闭。另一些只在需要的时候才启动，完成任务后就自动结束。）
整个其实tee_supplicant主逻辑都在这里。
3.2 tee_supplicant存放RPC请求的结构体
在tee_supplicant中用于接收和发送请求的数据都存放在类型为tee_rpc_invoke的结构体变量中。该结构体内容如下：
tee_rpc_invoke结构体中的数据展开之后的组成如图所示。
（怎么长这样，我还没拉源码瞅瞅）
（记得源码上有op-tee的os，还有个otp-tee-client的，这里写的都是关于client）
3.3 tee_supplicant中的无限循环
前面知道了守护进程的含义。
tee_supplicant启动后最终会进入一个无限循环，调用process_one_request函数来监控、接收、处理、回复OP-TEE的请求。
（不断地轮询监听）
process_one_request函数的内容和注释如下：
我看这个函数里面，好像是这个监听到请求就创建一个线程去继续等待监听来自TA的请求。这样就避免在处理的时候，来自其他的请求就处理不了，同时应该是有个限制，能创建的线程数。最多处理多少个TA的请求，以及这些函数是不是有锁的，这些都需要到源码中自己去好好看看。（我说我嘿嘿）
3.4 tee_supplicant获取TA的RPC请求
tee_supplicant通过read_request接收来自TA端的请求。该函数会阻塞tee驱动层面，其内容如下：
在OP-TEE驱动中ioctl的TEE_IOC_SUPPL_RECV操作将会阻塞，直到接收到来自TA的请求。关于驱动部分将在后续章节详细介绍。
3.5 TA RPC请求的解析
获取到来自TEE侧的RPC请求后，tee_supplicant会调用find_params函数来解析该RPC请求。该函数的内容和说明如下：
3.6 RPC请求的处理
当解析完来自TA的RPC请求，获取到具体参数后，在process_one_request函数中会根据请求的功能ID来决定具体执行什么操作。这些操作包括：
□ 从文件系统中读取TA的镜像保存在共享内存中；
□ 对文件系统中的节点进行读/写/打开/关闭/移除等操作；
□ 执行RPMB（EMMC中的RPMB分区）相关操作；
□ 分配共享内存；
□ 释放共享内存；
□ 处理gprof请求；
□ 执行网络socket请求。
3.7 回复RPC请求
当tee_supplicant解析出RPC请求的功能ID，并根据该ID找到对应的处理函数，完成TEE请求操作后，tee_supplicant通过调用write_response函数将处理结果和数据返回给TA。
该函数的内容和解释如下：
（ioctrl这函数太强了，必须得学习一下。）
对于这个part就到这里了，下面就是把创建CA的步骤重新一篇，然后研究一下这个RPC请求。
下一篇RPC请求的处理。
小少爷先休息一下吧。