1、软件架构

最近在需要设计一个CA，虽然学习了一些相关的方面。但是做设计的时候，对于调用关系还是因为缺乏宏观的架构认识，做的时候就还是很不顺畅。这里先来瞅瞅。

要使用OP-TEE来实现特定的安全功能就需要开发者根据自己的实际需求开发特定的CA和TA程序，并将TA集成到OP-TEE中。

CA端负责实现在RTOS端userspace层面的对外接口，而TA端的代码则是在OP-TEE OS的userspace层面负责实现具体的安全功能，例如使用何种算法组合来对数据进行安全处理，对处理后的数据的安全保存，解密加密数据等等功能。

（CA和TA都是用户层的）

下图为系统中CA与TA之间执行的软件框图。

借助OP-TEE来实现特定安全需求时，一次完整的功能调用一般都是起源于CA，TA做具体功能实现并返回数据到CA，而整个过程需要经过OP-TEE的client端接口，OP-TEE在Linux kernel端的驱动，Monitor模式下的SMC处理，OP-TEE OS的thread处理，OP-TEE中的TA程序运行，OP-TEE端底层库或者硬件资源支持等几个阶段。

当TA执行完具体请求之后会按照原路径将得到的数据返回给CA。

由于每家对具体API的具体实现不一样，但是其功能和对外接口都是遵循GP的标准来做的，笔者就遇见海思和mstar在实现CA端的API的时就各有各的方式，其中海思的实现更加复杂一点，因为海思在添加TA和CA的时候，在驱动层和TEE端都会对调用TEE服务的process或者thread做权限检查，建立了类似白名单机制，在海思的TEE中添加TA和CA的时候必须要注意CA端调用的process的注册。

由于当前所有厂商的TEE方案都会遵循GP标准，OP-TEE也遵循GP(Global Platform)标准，本文中牵扯到的API的实际实现则以OP-TEE中的source code为准。

2、CA接口调用的完整流程----系统各层面关系

二级厂商需要实现自有feature的时候，需要添加自己的TA和CA接口，当CA部分的接口需要提供给APP层面调用的时候，一般做法是在framwork中建立特定的service，在service中调用CA接口。

同时也会建立对应的client部分，client部分与service部分通过Binder的方式进行同行来实现触发CA接口调用的操作。而对于APP层面，开发者会将client部分提供的接口以JNI的方式进行封装暴露给上层APP调用。

当上层APP调用封装好的JNI接口之后，CA接口是如何通知特定的TA执行特定操作的呢？CA与TA之间的数据是如何传递的呢？cortex的状态是如何切换的呢？本文将详细讲解一次CA接口调用后功能实现的完整流程（本文不讨论FIQ和IRQ的情况，只讨论通过调用SMC指令调用到TEE的情况）。

1.支持TEE的系统各层面关系图

下图为层面结构图：

当CA接口处于userspace层面，整个调用过程需要经过kernel space层面， linux driver层面， Monitor态中断处理层面， TEE OS kernel层面， TEE的userspace层面（TA）。

2.userspace到kernelspace

在userspace 层面调用CA接口之后会触发system call操作，系统调用会将Linux陷入内核态，此时系统处于kernel space，然后根据传入的参数，找到对应的TEE driver，整个过程的过程大致如下：
（在这个部分，一直是讲TEE driver和tee os的driver搞混淆了）

关于该部分更加详细的内容，例如：软中断如何在kernel中注册的，系统调用的定义等等可查找系统调用（systemcall）和驱动的相关资料进行了解

3.TEE driver到monitor态

在TEE的driver中，最终会调用SMC这条汇编指令来实现与OP-TEE的沟通，当调用SMC汇编指令之后，会触发SMC软中断，该软中断的处理在Cortex的Monitor态中进行，随着ARM提供了ATF（ARM trust firmware），SMC的软中断具体处理函数在ATF中被实现，该软中断会根据发送指令是属于安全侧请求还是非安全侧的请求来控制是将cortex切换到secure world态还是non-secure world态。该切换动作在ATF的SMC中断处理函数中被实现。

如果没有，TEE OS将会与常驻在linux中的tee_supplicant进程通信，从文件系统中获取到TA image文件，并传递給TEE OS，然后加载该TA image。

处理完整之后，TEE OS会切换到TEE userspace态，并将CA传递过来的其他参数传给具体的TA process，TA process获取到参数后，首先需要解除出参数中的commond ID值，根据具体的command ID值来做具体的操作。

当然TEE OS在加载TA image的时候会有电子验签操作来验证TA image的合法性。上述步骤的大致流程图如下：

由于一次完整的CA调用过程需要做一次调用执行initContext, Opensession, InvokeCommand, close session, FinalizeContext操作，所以上图只是大致流程，关于详细部分将会在后期章节中节后代码逐步讲解。

5.GP规定的C端接口

在GP中规定的CA端接口较少，主要的是五个接口，分别如下：

TEEC_InitializeContext: 初始化TEE context，完成open tee driver，建立与TEE之间的context

TEEC_OpenSession: 建立CA与TA之间的会话窗口

TEEC_InvokeCommand: 想TA发送执行请求来执行具体的操作

TEEC_CloseSession: 关闭CA与TA之间的会话窗口

TEEC_FinalizeContext:清空建立的contex

。。。

共有十个，在前面学习TACA系列–怎么创建一个CA的时候，有记录过。

参考资料：
《手机安全和可信应用开发指南:TrustZone与OP-TEE技术详解》
https://blog.csdn.net/shuaifengyun/article/details/71697371

OP-TEE中TA与CA调用的完整流程----系统各层面关系相关推荐

TEE中TA和CA的编译
原 2. OP-TEE中添加自己的TA和CA 2017年05月10日 12:46:50 漂流的猴子阅读数:5862更多 <div class="tags-box space" ...
19. OP-TEE中TA与CA执行流程详解-------软件架构篇
历经一年多时间的系统整理合补充,<手机安全和可信应用开发指南:TrustZone与OP-TEE技术详解 >一书得以出版,书中详细介绍了TEE以及系统安全中的所有内容,全书按照从硬件到软件, ...
22. OP-TEE中TA与CA执行流程-------tee-supplicant（一）
历经一年多时间的系统整理合补充,<手机安全和可信应用开发指南:TrustZone与OP-TEE技术详解 >一书得以出版,书中详细介绍了TEE以及系统安全中的所有内容,全书按照从硬件到软件, ...
21. OP-TEE中TA与CA执行流程-------libteec介绍
历经一年多时间的系统整理合补充,<手机安全和可信应用开发指南:TrustZone与OP-TEE技术详解 >一书得以出版,书中详细介绍了TEE以及系统安全中的所有内容,全书按照从硬件到软件, ...
2. OP-TEE中添加自己的TA和CA
历经一年多时间的系统整理合补充,<手机安全和可信应用开发指南:TrustZone与OP-TEE技术详解 >一书得以出版,书中详细介绍了TEE以及系统安全中的所有内容,全书按照从硬件到软件, ...
35. OP-TEE中基本算法接口调用实现
历经一年多时间的系统整理合补充,<手机安全和可信应用开发指南:TrustZone与OP-TEE技术详解 >一书得以出版,书中详细介绍了TEE以及系统安全中的所有内容,全书按照从硬件到软件, ...
GP TEE中的几种存储方式介绍
转载:https://cloud.tencent.com/developer/article/1043705 我们知道TEEOS最重要的功能莫过于安全存储了,这是一切安全的前提,根据存储安全性和使用场 ...
在 C# 中通过 P/Invoke 调用Win32 DLL
,.NET Framework 1.0 或 1.1 版类库中存在任何 Windows 所没有的功能限制都不足为怪.毕竟,32 位的 Windows(不管何种版本)是一个成熟的操作系统,为广大客户服务了 ...
java冒泡排序函数验证_java冒泡排序-选择排序-插入排序-使用API中文文档直接调用函数...
import java.util.Arrays; public class ArrayDemo2_3 { public static void main(String []args) { //---- ...

OP-TEE中TA与CA调用的完整流程----系统各层面关系