OPTEE：TA和TA加载（一）
前言
最近老师给了个作业，让做一下TA的镜像校验，而我是什么都不知道？甚至以前都没听过这个。于是将这个任务拆分成了三个部分，最后也就是学习的三篇笔记。
TA动态加载流程是什么？
TA验签流程是什么？
怎么制作TA的签名？
这是我在看了关于TA的一些基础的知识之后，选择的一个方式，可能连起的这个名字都不是很专业，哈哈。
没事学习不就是一个发现问题解决问题的过程。
我会在每个部分，把相关的基础知识先放在前面。这个会以我自己的疑问的方式进行提出与解答。
1、都在说TA动态加载，那么TA是什么？
你首先得知道什么是trustzone，然后再看看这个图：
TA：Trust Application，就是在TEE中执行的可信应用。就像钱包、通信录这些比较私密的应用。为什么要把它放在可信任的环境，你说要是把你的通信录、信息、钱包等软件和那些有毒的软件放到一起，那早就把你的钱从后台给你整完了。
但是这个理解或者是解释又太狭隘了，TA这个不但是个应用能形容的。
TA分为Static TA 和 Dynamic TA两种
静态TA运行在内核模式中，就是随着内核镜像的生成的时候，就生成了。不好的地方就是修改TA还得重新编译镜像。
动态TA运行在用户模式中，一般存储在文件系统中，通过TEE_Supplicant被OP-TEE加载。就是运行起来后还可以加载镜像。
（其实这里有没有想到，咱们手啊，为什么有的应用是手机开机就有，还卸载不掉。有的支付宝等应用可以安装。）
静态TA只是一个接口，它不是TA本身，静态TA是将特殊服务暴露给动态TAs和客户端的一种方式。静态TA可以通过调用TEE内核中的任何驱动程序代码直接访问硬件。 这意味着您可以使用静态TA扩展内部API提供的服务，而无需添加任何新的系统调用。（这我想的意思就是通过静态TA可以实现一些正儿八经的TA应用）
看看这个图，动态TA可以使用Internal Client API与静态TA进行通信。（不知道这里可不可以理解为静态TA是动态TA的基石之一？两者共同实现了TA？）我也不知道，那么继续往下干。
OPTEE，是一个teeos，OP-TEE支持动态TA和静态TA。
静态TA镜像将与OP-TEE镜像编译在同一个镜像文件中，因此静态TA镜像会存放在OP-TEE镜像的特定区段中，静态TA在OP-TEE启动时会被加载到属性为MEM_AREA_TA_RAM的安全内存中。
动态TA则是将TA镜像文件保存到文件系统中，在创建会话时OP-TEE通过发送RPC请求将动态TA镜像加载到OP-TEE的安全内存中。
创建会话在OP-TEE中的操作是根据TA对应的UUID值找到对应的TA镜像，读取TA镜像文件的头部数据，并将相关数据保存到tee_ta_ctx结构体变量中，然后将填充好的tee_ta_ctx结构体变量保存到tee_ctxes链表中，以便后期CA执行调用TA命令操作时可通过查找tee_ctxes链表来获取对应的会话。最后根据会话的内容进入到指定的TA，根据需要被调用的命令的ID执行特定的操作。（这里CA调用的是静态TA还是动态TA？或者是他们两个组成的TA，）
可见这个并不是分工那么明确，其实两者某种程度是功能一样的不同形式。
到这里其实经过一阵迷茫后，可以体会到上文的意思：
静态TA运行在内核模式中
接口，不是TA本身
将特殊服务暴露给动态TA和客户端的一种方式
可以调用TEE内核中任何驱动程序代码直接访问硬件，这意味着可以使用静态TA扩展内部API提供的服务，而无需添加任何新的系统调用
Dynamic TA
动态TA运行在用户模式中，一般存储在文件系统中，通过TEE-Supplicant被OP-TEE加载，可以使用Internal Client API与静态TA进行通信
就是静态的TA的意思是一些系统级别的安全调用，可能被上层的动态TA需要，也可能被CA需要。所以说静态更能说是一种接口，而不是应用本身。（这里我觉得指纹、人脸这些，都是需要系统级别的。CA：支付宝）
动态TA就是一些本身就很安全的应用，比如通信录、信息这些，或者第三方厂商本来自带的钱包应用等。
还有些需要获取通信录的、联系人的这些，这就是从CA到TA的调用，以上的栗子应该能体会到CA可能需要静态TA或者动态TA。（栗子可能不准，但是这个意思请你get到，有什么错误欢迎指出。）
对于TA的理解，继续学习。产生新的体会。
2、TA怎么用的
前面这个图
知道了CA可能会调用静态TA，也可动态TA，动态TA也可能调用静态TA，下面这会话的创建，那么肯定就以动静态分开整。
下面首先看看静态调用时的会话创建：
2.1 、静态TA的创建会话操作
前面知道静态TA是与OP-TEE OS镜像编译在一起的，在OP-TEE的启动阶段，静态TA镜像的内容会被加载到OP-TEE的安全内存中，且在启动过程中会调用verify_pseudo_tas_conformance函数对所有的静态TA镜像的内容进行检查。（安全启动是个构建信任链的过程，会对这个链的每一步都进行检查。）
调用创建会话操作后，OP-TEE首先会在已经被创建的会话链表中查找是否有匹配的会话存在。（毫无疑问，为了提升速度）
如果找到则将该会话的ID直接返回给REE侧，如果没有找到则会根据UUID去静态TA的段中进行查找，然后将找到的静态TA的相关信息填充到tee_ta_ctx结构体变量中，再将该变量添加到全局的tee_ctxes链表中，并调用静态TA的enter_open_session函数执行创建会话操作。（这个UUID就是唯一的标识符）
来看看通过UUID去寻找静态TA的过程：
如果CA调用的是静态TA, OP-TEE会到存放静态TA的ta_head区域通过遍历的方式，对比内存中静态TA区域中TA的UUID与需要调用的TA的UUID值是否相等找到需要被调用的静态TA：调用tee_ta_init_pseudo_ta_session函数来实现的。
__start_ta_head_section到__stop_ta_head_section区域之间保存的是所有静态TA的ta_head数据。
在编译各静态TA时，通过使用pseudo_ta_register宏将各静态TA的ta_head数据保存到ta_head_section段中，该段的起始地址是__start_ta_head_section，结束地址是__stop_ta_head_section。
2.2 pseudo_ta_ops变量
OP-TEE对所有静态TA的操作接口都保存在pseudo_ta_ops变量中，该变量的enter_open_session成员的值为pseudo_ta_enter_open_session，该函数指针会检查具体TA中的相关函数是否有效并执行相应的操作，该函数的内容和注释如下：
其实发现有很多的实现都是将实现放在一个链表或者数组中
2.3 pseudo_ta_register宏
在编译过程中，该宏将静态TA的ta_head数据保存到ta_head_section段中，该宏的定义如下：
一个静态TA的ta_head数据中保存了该静态TA的UUID、name、flags，以及初始化该TA操作接口的函数指针。（所以在head中找到了就找到了）
以提供网络socket服务的静态TA为例，使用该宏时的内容如下：
在该示例中定义了网络socket服务静态TA提供的创建会话、关闭会话、调用命令的操作实现。
（指定，然后找到，最后执行相应的操作）
3 动态TA的创建会话操作
动态的TA镜像存放在REE侧的文件系统中。（所以啊需要加载，所以啊加载了就需要校验）
CA在执行动态TA的创建会话操作时，OP-TEE会根据UUID值借助RPC机制让tee_supplicant将动态TA镜像加载到OP-TEE的内存中，并获取加载到内存中的动态TA的相关信息，将这些信息填充到tee_ta_ctx结构体变量中，然后再将该变量添加到全局的tee_ctxes链表中，以便后续CA端调用该TA中的命令操作时，可直接根据会话ID值从链表中找到对应的会话。
加载动态TA镜像到OP-TEE中是通过调用tee_ta_init_user_ta_session函数来实现的，该函数会调用ta_load函数发送RPC请求从REE侧的文件系统中加载动态TA镜像到OP-TEE中。
在将TA镜像的内容写入到OP-TEE的内存中之前，OP-TEE会对该TA镜像中的内容进行电子验签，以确保该TA镜像的合法性。
动态TA的创建会话操作整体过程如图13-3所示。
动态TA运行在OP-TEE的用户空间，创建会话操作最终会切换到用户态，调用到具体动态TA的创建会话接口函数TA_OpenSessionEntryPoint。（静态TA是内核态）
（我关注的是动态TA加载前的的签名校验过程，后面会讲到）
1．动态TA的加载
动态TA的镜像文件被保存在REE侧的文件系统中。
在第一次执行创建会话操作时首先需要将REE侧的动态TA镜像文件加载到OP-TEE中，并初始化该TA的运行上下文。
这些操作是通过调用tee_ta_init_user_ta_session函数来实现的，该函数内容和注释如下：
user_ta_ops变量用于保存在OP-TEE内核空间中操作动态TA的接口函数的指针，其内容如下：
当动态TA被加载到OP-TEE中后，OP-TEE会调用user_ta_ops中的enter_open_session成员变量所指向的函数进一步处理CA创建会话的请求。
参考资料：
《手机安全和可信应用开发指南》